FreeBSD 10 on Dockstar (Marvell Kirkwood)
Ian Lepore
ian at FreeBSD.org
Fri Jan 3 18:11:41 UTC 2014
On Fri, 2014-01-03 at 17:59 +0000, 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 information is in a PDF document from Marvell:
http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
The info is a little hard to puzzle out. The 0x2f is the attribute for
mapping NAND flash; it's found near the end of Table 4.
Because the attribute value was wrong in that dts you were using (it's a
value not even listed in the table) I suspect it was making some kind of
crazy dram or other device mapping that was interfering with normal
memory access.
> > Markus, could you please test this; if it works, I'll commit it. The
> > only marvell hardware I have for testing is DreamPlug.
>
> It does indeed work. I am a bit surprised that noone seems to be running
> FreeBSD on a dockstar seriously enough to run into these problems.
>
> Some ugly problem in connection with USB seems to rear it's head atm: if I
> fsck a filesystem, it finds a lot of DUPs and starts deleting perfectly fine
> files. I changed to using sync as well as disabling clustered reads and
> writes. Maybe I'll find the time to investigate this issue as well.
>
This sounds a bit similar to a problem posted some weeks (hmmm, at this
point maybe some months) ago relating to data corruption on USB disk IO
on a SheevaPlug (same kirkwood chip). I wasn't able to recreate it then
with a quick minimal effort. I need to put better effort into it soon,
I think.
> I hacked a bit on the gpio/led driver to make the LED work with gpioled, I'll
> post a patch to the mailing list when it's cleaned up if that's ok.
By all means. That might even be something I can use; my DreamPlugs
have LEDs, and the green one is crazy-bright, I'd love to turn it off.
Either way, I can get it committed for you.
-- Ian
More information about the freebsd-arm
mailing list