FreeBSD 10 on Dockstar (Marvell Kirkwood)

[Ian Lepore]

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