Re: I2O on sparc64 [Also on alpha] (Was: Re: mlx on sparc?)

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Thu, 5 Jun 2008, Jan-Hinrich Fessel wrote:

> Am 05.06.2008 um 16:31 schrieb Andrew Doran:
>
> > It looks like the board actually did reset OK. Can you give this patch
> > a try?
> >
> >         http://www.netbsd.org/~ad/iop.c.diff
> >
> > Andrew
> Didn't help much - now it waits longer (actually until the KITT phase), but 
> still reset rejected.  Could this be an endian issue despite the 
> letoh32/htole32 conversion?
> Anyway, since the exit code is 0x0 and not IOP_RESET_REJECTED, I changed 
> iop.c to ignore the status if it's 0...
>
> Now I get:
> Distributed Processing Technology Memory Controller (miscellaneous memory, 
> revision 0x02) at pci2 dev 3 function 0 not configured
> iop0 at pci2 dev 4 function 0: I2O adapteriop0: reset rejected, status 0x0
> iop0: STATUS_GET timed out
> iop0: not responding (get status)
>
> which doesn't really bring us that much progress.
>
> What next - and I already exchanged the controller for a known good unit...

  Was there any further progress with this?

  I have an AlphaServer ES40 and an AlphaServer ES45 with an I2O 
controller.  Back when I was playing on the ES40, I had added iop(4) to
the alpha kernel config, only to have it fail.  I don't remember the 
details at the time, and didn't spend too much time trying to debug it.
I had an mlx(4) controller that I had added to the ES40 since OpenVMS 
didn't support the I2O controller.

  I am now playing around with an ES45, which wasn't supported at all, but 
I have gotten it to boot up and probe all the pci hose now.  It has a 
couple of Emulex fiber interfaces, which again have no driver available. 
I added the iop(4) to the kernel configuration and had it fail in the same 
manner as described in this thread.

  It looked like it should be working, but as Andy mentioned in a later 
message, the reset status and the status_get data never show up in memory.
After digging into the alpha busdma trying to re-familiarize myself with 
alpha DMA again, I realized that the 'physical address' used by the 
iop_reset() and iop_status_get() functions was a 'real' physical memory 
address.  However, the alpha uses a different address space for the DMA 
addresses.  The first 1G (I think) of physical memory is "direct-mapped', 
but at an address base of 0x80000000, and the remaining memory is access 
through the alpha sgmap address space (at a different address base). 
I.e., the physical address 0x2f4000 is addressed at 0x802f4000 in the DMA 
address space.

  After hacking the iop(4) driver to convert the physical address to a
DMA address, I was able to get the iop(4) driver to work on the 
AlphaServer ES45 quite nicely.

  I'm not all the familiar with the bus_dma routines, but it appears that 
the problem is due to using bus_dmamem_alloc() to allocate the scratch and 
reply memory, and doing bus_dmamem_map() and bus_dmamap_load() on them.
On the alpha, this results in a "real" physical memory address in the dma 
segments, which doesn't work.  I'm in the process of trying to figure out 
if the current method is incorrect and if so, how to fix it.

  I'm even less familiar with the sparc64 DMA, but I'm wondering the the 
same type of thing is happening there (i.e., the DMA addressing is not 
real physical memory, but mapped through DMA mappings).

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA