Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Jan 2014 15:05:22 -0500
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        freebsd-arm@FreeBSD.org, Markus Pfeiffer <markus.pfeiffer@morphism.de>
Subject:   Re: FreeBSD 10 on Dockstar (Marvell Kirkwood)
Message-ID:  <52C71802.9040304@freebsd.org>
In-Reply-To: <1388779369.1158.303.camel@revolution.hippie.lan>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52C71802.9040304>