From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 20:02:55 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 35CF621A; Fri, 3 Jan 2014 20:02:55 +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 E814A1EE0; Fri, 3 Jan 2014 20:02:54 +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 1VzAxJ-000FiG-V9; Fri, 03 Jan 2014 20:02:54 +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 s03K2o4J024270; Fri, 3 Jan 2014 13:02:50 -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/HLsZa8ssTLPR3GaEy79XA Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Nathan Whitehorn In-Reply-To: <52C7141C.2040801@freebsd.org> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <52C70B9B.9090205@freebsd.org> <1388778165.1158.302.camel@revolution.hippie.lan> <52C7141C.2040801@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 13:02:49 -0700 Message-ID: <1388779369.1158.303.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, Markus Pfeiffer 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 20:02:55 -0000 On Fri, 2014-01-03 at 14:48 -0500, Nathan Whitehorn wrote: > On 01/03/14 14:42, Ian Lepore wrote: > > On Fri, 2014-01-03 at 14:12 -0500, Nathan Whitehorn wrote: > >> On 01/03/14 12:59, 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 ranges field, as per IEEE 1275 (page 175), provides a mapping from > >> addresses in a child address space to the parent. It is a set of tuples > >> of (child base address, parent base address, size), with the field > >> widths being (#address-cells on this node [2], #address-cells of parent > >> bus [1], #size-cells on this node [1]). This mapping table is used for > >> resource allocation of children, to map bus-local requests for addresses > >> to addresses on the parent bus (in this case, physical memory > >> addresses). In this case, the following: > >> > >> ranges = <0x0 0x2f 0xf9300000 0x00100000> > >> > >> means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. > >> > >> Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. > >> -Nathan > > So now we're back to the usual question... do we adhere to published or > > defacto standards? The defacto standards for arm dts files are > > basically "whatever linux does is right by definition" (::sigh::), and > > what we've got in the marvell dts files right now is basically similar > > to what linux uses (I think linux has evolved a bit since our dts files > > were created; they were probably compatible at some point). > > > > Here's what linux is doing these days. I notice they've moved the > > mapping info from "mrvl,lbc" to "marvell,kirkwood-mbus", "simple-bus"; > > > > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi > > > > -- Ian > > > > > > > > I don't see any particular way in which these files violate the > standards. Did I miss something? In this case, so long as a 1:1 linear > mapping can be made, it's perfectly alright for "child bus addresses" to > be basically arbitrary codes, as here. IEEE 1275 PCI does this, for > example, with 96-bit "child address" ranges that are a combination of > the bus, slot, and function for the card along with actual 64-bit memory > locations. In general, Linux's device tree support seems to be much more > standards-compliant than ours. It's FreeBSD that seems to take the more > fragile and ad-hoc approach, which is what usually creates this "I have > to go patch my DTS now" problem. > -Nathan Well then I'm confused. You described a 3-tuple, and our dts and linux use a 4-tuple. I actually don't know what the first number in ours is even there for, it doesn't seem to be used in the code. -- Ian