Hello,

I think I have the answer to my own question... Here's a patch to the powerpc
port's bus_dma.c file that fixes the problem for me, and looks correct given
(a) the other places in this source file that set the ds_addr value, and (b)
how some of the other bus_dma.c implementations handle this:


Index: sys/arch/powerpc/powerpc/bus_dma.c
===================================================================
RCS file: /usr/NetBSD/src/sys/arch/powerpc/powerpc/bus_dma.c,v
retrieving revision 1.10
diff -c -r1.10 bus_dma.c
*** sys/arch/powerpc/powerpc/bus_dma.c  2003/04/09 22:28:56     1.10
--- sys/arch/powerpc/powerpc/bus_dma.c  2003/04/18 08:20:38
***************
*** 325,331 ****
                                error = EFBIG;
                                continue;
                        }
!                       map->dm_segs[seg].ds_addr = lastaddr;
                        map->dm_segs[seg].ds_len = m->m_len;
                        lastaddr += m->m_len;
                        continue;
--- 325,332 ----
                                error = EFBIG;
                                continue;
                        }
!                       map->dm_segs[seg].ds_addr = PHYS_TO_BUS_MEM(t,
lastaddr);
! 
                        map->dm_segs[seg].ds_len = m->m_len;
                        lastaddr += m->m_len;
                        continue;


Comments?

John...

--- John Gordon <john_94501@yahoo.com> wrote:
> Hello,
> 
> Well, after much hunting and a lot of debug code I have tracked down why my
> NS
> 1000 was unable to send anything over the network, despite being able to
> receive packets correctly. Problem is I am not certain of how to solve it
> correctly...
> 
> The problem is simple: the address of the data that is being inserted into
> the
> transmit descriptor is not a PCI address, but a CPU address. On the NS 1000,
> as
> with many PPC systems, the main memory is in the 0 -> 2GB portion of the
> CPU's
> address space, but from the PCI side of the host bridge it is in in the 2GB
> ->
> 4GB range.
> 
> Now, the code in the pcn_start() routine is as follows:
> 
> if (sc->sc_swstyle == LE_B20_SSTYLE_PCNETPCI3) {
>     for (nexttx = sc->sc_txnext, seg = 0;
>         seg < dmamap->dm_nsegs;
>         seg++, nexttx = PCN_NEXTTX(nexttx)) {
>         /*
>          * If this is the first descriptor we're
>          * enqueueing, don't set the OWN bit just
>          * yet.  That could cause a race condition.
>          * We'll do it below.
>          */
>         sc->sc_txdescs[nexttx].tmd0 = 0;
>         sc->sc_txdescs[nexttx].tmd2 =
>             htole32(dmamap->dm_segs[seg].ds_addr);
>         sc->sc_txdescs[nexttx].tmd1 =
>             htole32(LE_T1_ONES |
>                 (nexttx == sc->sc_txnext ? 0 : LE_T1_OWN) |
>                 (LE_BCNT(dmamap->dm_segs[seg].ds_len) &
>                  LE_T1_BCNT_MASK));
>         lasttx = nexttx;
>     }
> }
> 
> The line in the middle of that loop that sets tmd2 is correctly handling the
> translation to PCI's little endian, but it is not dealing with the difference
> between the CPU's view of the address space, and the PCI bus' view of the
> address space.
> 
> So, how do I fix this? Is the problem in this piece of code, or should the
> ds_addr value already have been translated to a PCI-view address? Obviously,
> for my testing it is simple to just set the top bit on the address, but how
> do
> I do this correctly, and where (in the driver here, or in the DMA code that
> sets up the ds_addr value in the first place)?
> 
> Suggestions welcomed...
> 
> Thanks,
> John...
> 
> =====
> Rate Corporate America at http://exec-ratings.bluedonkey.org
> 
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com


=====
Rate Corporate America at http://exec-ratings.bluedonkey.org

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com