From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 20:05:26 2014 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 ESMTPS id 1C04A3D3; Fri, 3 Jan 2014 20:05:26 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA0BB1F03; Fri, 3 Jan 2014 20:05:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYU00A00CKKV000@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 14:05:24 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.3.195714, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYU008TLD4YS300@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 14:05:23 -0600 (CST) Message-id: <52C71802.9040304@freebsd.org> Date: Fri, 03 Jan 2014 15:05:22 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) 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> <1388779369.1158.303.camel@revolution.hippie.lan> In-reply-to: <1388779369.1158.303.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 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:05:26 -0000 On 01/03/14 15:02, Ian Lepore wrote: > 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 > > It's a 3-tuple, but each element is not necessarily one cell. The element width is described by the #address-cells and #size-cells properties. For localbus, child addresses are defined to be two cells wide (64 bits) by the localbus node's #address-cells property. The parent's addresses are one cell (parent node #address-cells), as is the size property (localhost #size-cells). So a single 3-element table entry is 2+1+1=4 cells wide. -Nathan