FreeBSD 10 on Dockstar (Marvell Kirkwood)

[Nathan Whitehorn]

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