Hmm... this is new code I wrote, which I did to try to fix it so that
the address space allocated from PCI space for devices did not conflict
with the space associated for the memory window back to the host.  (I.e.
I assumed that either YAMON or the platform initialization logic would
establish pci_mbar and pci_mwmask reasonably, and that
pci_configure_bus() logic would operate properly when given reasonable
start and end addresses.

On the dbau1550 the pci_mbar/mwmask registers should result in the first
addresses starting at 0x20000000 of PCI bus space, which should *not*
correspond to any address decoders elsewhere on the platform.

KIYOHARA Takashi wrote:
> Hi! all,
>
>
> The PCI_NETBSD_CONFIGURE doesn't operate correctly in our alchemy-boards. 
> Devices that the map is done fails in the first PCI memory space without
> fail.  It is because register AUPCI_MBAR is 0x00000008.  (see description
> of pci_mbar in 'AMD Alchemy Au1550 Processor Data Book')
>
> e.g. (YAMON on Open Micro Server)
> ---------------------------------
>   YAMON> dump b4005110 10
>
>   B4005110: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>            ^^^^
>
> This value will set mstart to 0x20000008.  And, au_himem_space_init() will
> be called.
>   
Ah.  And this is the bug!  I need to set mstart using the mask properly
rather than just adding it.  I was assuming that the mbar would start at
aligned on the mwmask.  Stupid me.

The solution is to change aupci to fix that assumption:

remove the calculation for sz around aupci.c:231, and instead have
mstart calculated like this:

mstart = (mbar & ~mask) + (1 + ~mask);

That should get the pci addresses aligned.

I don't understand fully why the devices I'm working with don't seem to
have run into this problem -- maybe they are using IO mapped addresses
rather than memory mapped.  I need to research that further.

Unquestionably you have found a bug, and hopefully the above change will
fix it.  I'll commit it shortly if no one disagrees.
> However, macro PCI_MAPREG_MEM_ADDR() of pciconf.c::setup_memwins() is
> allocated masking 0xfffffff0.  In a word, it allocates 0x20000000 in wm0
> on OMSAL400.
>
>   wm0 at pci0 dev 3 function 0: Intel i82541GI 1000BASE-T Ethernet, rev. 5
>
>   ... snip ...
>
>     Type 0 ("normal" device) header:
>       0x10: 0x20000000 0x00000000 0x01000001 0x00000000
>       0x20: 0x00000000 0x00000000 0x00000000 0x10768086
>       0x30: 0x00000000 0x000000dc 0x00000000 0x00ff0100
>       
>       Base address register at 0x10
>         type: 32-bit nonprefetchable memory
>         base: 0x20000000, size: 0x00020000
>   
>   ... snip ...
>
>   wm0: unable to map device registers
>
>
>
> Are it necessary that we do the mask with PCI_MAPREG_MEM_ADDR()?
> Or, any ideas?
>   

See my change above.
>
> Index: aupci.c
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/mips/alchemy/dev/aupci.c,v
> retrieving revision 1.3
> diff -u -r1.3 aupci.c
> --- aupci.c     16 Feb 2006 01:55:17 -0000      1.3
> +++ aupci.c     26 Feb 2006 17:30:14 -0000
> @@ -232,7 +232,7 @@
>         sz = 1 + ~mask;
>  
>         mbar = bus_space_read_4(sc->sc_bust, sc->sc_bush, AUPCI_MBAR);
> -       mstart = mbar + sz;
> +       mstart = PCI_MAPREG_MEM_ADDR(mbar + sz);
>         mend = 0xffffffff - mstart;
>  
>         sc->sc_memt = &sc->sc_mem_space;
>
> Thanks,
>   
Nope, this isn't right.  It will make your platform work, but it won't
solve the problem e.g. if mstart is set to some other value that is  16
byte  aligned but not aligned on an mwmask boundary.

Again, please accept my humble apologies.

    -- Garrett
> --
> kiyohara
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191