Subject: Re: Marvell EV64260
To: None <D.Fraser@flarion.com>
From: Derek God3 <firstname.lastname@example.org>
Date: 03/18/2004 09:07:01
while I don't use ev64260 I do use evbppc and yes I
too needed to adjust segments/bus spaces/dma/interrupt
schemes/boootloader interfaces/packaging ....... all
I can say is that its better now than used to be and
continues to improve. You might also find sepcficly
that your phys_to_bus_mem needs to be different
for PCI vs PLB/OLB so ibm4xx_setup_pci() might need
to insert a different dmat->_dma_*
> SO this seems to be the place to post ev64260 issues.
> I have recently built netbsd-current for this board.
> I am using PMON2000 as a boot monitor, booting netbsd
> via TFTP from a netbsd x86 box. Things for the most part
> are fine. I had to add a few lines to the config file
> options USER_SR=9
> options KERNEL_SR=10
> options KERNEL2_SR=11
> to avoid having the kernel malloc pages buried beneath
> the PCI BATs. Has anyone else bumped into this? I
> was surprised to fins a non-runner issue so soon in
> the process.
> It loads and starts, but halts in gtmpscattach().
> (called from consinit(). I have configured MPSC as console)
> If I bail early from that function, it comes all the way
> up until init.
> I went back to visit gtmpscattach(), and find that it
> fails down in the dma map routines, particularly,
> PHYS_TO_BUS_MEM is undefined, and the resulting structure
> entry in bus_dma_tag_t (*(t)->_dma_phys_to_bus_mem) is
> left NULL, which on dereference, causes an exception.
> Some ports define this macro and others bypass it
> entirely by using their own bus.h associated source files.
> In this case, neither quite seems to be true.
> Has anyone else dealt with this already?
> What is the preferred solution?
> (NOTE: I am old to embedded, new to NetBSD)