Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index