I have found one more problem which may force the separate port issue, 
unless I want to go the path of fixing all of the evbmips ports (I do not).

In order to provide access to the PCI bus, I need to supply a reasonable 
bus_space implementation.  Unfortunately, if I want to run my platform 
big-endian (I do), then I run into a problem.

The problem is that most of the bus_space_XXX routines are intended to 
provide automatic conversion from bus order to native order.  So most 
drivers don't have to have special endianness checks in them.

However, sometimes you want to be able to pull off a bunch of data in 
word-based quantities *without* swapping words.  The wi(4) driver does 
this.  For this you need to have streaming versions of the bus_space 
routines.

The problem is that evbmips follows the stock MIPS notion of just 
#define'ing these routines to be the same as their non-streaming 
counterparts.

This doesn't work when the bus and cpu have different endiannesses.

Maybe I'm missing some obvious point here, but basically a lot of this 
work was found empirically by testing different configs.

By the way, if you're familiar with the Au1XXX parts, here's how I'm 
configuring the native endianness mapping on the processor.  If I'm 
doing something stupid here and you can see it, I'd appreciate hearing 
about it:

#if defined(__MIPSEB__)
    cfg = AUPCI_CONFIG_CH | AUPCI_CONFIG_R1H |
        AUPCI_CONFIG_R2H | AUPCI_CONFIG_AEN |
        AUPCI_CONFIG_SM | AUPCI_CONFIG_ST |
        AUPCI_CONFIG_SIC_DATA;
#else
    cfg = AUPCI_CONFIG_CH | AUPCI_CONFIG_R1H |
        AUCPI_CONFIG_R2H | AUPCI_CONFIG_AEN;
#endif
    bus_space_write_4(sc->sc_bust, sc->sc_bush, AUPCI_CONFIG, cfg);


This looks pretty similiar to what the Linux code sets up.  I still have 
to swap bytes in bus_space_read_2, etc. using letoh16, etc.

By the way, I'm just about at the point of having PCI working.  It works 
well enough until the streaming logic comes into play with wi(4).  (For 
example, I can get my IEEE1394 host controller working.)

    -- Garrett

Garrett D'Amore wrote:

> Simon,
>
> First off thanks for getting back to me.  More detail follows:
>
> Simon Burge wrote:
>
>> Hi Garrett,
>>
>> On Fri, Sep 30, 2005 at 03:36:43PM -0700, Garrett D'Amore wrote:
>>
>>  
>>
>>> Andrey Petrov wrote:
>>>
>>>   
>>>
>>>> On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
>>>>
>>>> If you need 36-bit address (constant prefixes even) only for PCI 
>>>> access then
>>>> likely you can work it out in your bus_.. functions. And that 
>>>> wouldn't justify
>>>> larger paddr_t and new port, I understand temptation thou -)
>>>>
>>>>     
>>>
>>> Hmmm... looking at this, the problem isn't just setting up DMA, but 
>>> also setting up the MMU mappings.  I'm pretty sure that the new port 
>>> is the right way to handle this.
>>>
>>> There is precedent -- the ARC port does much the same thing.  
>>> Actually, it does this apparently because of a need to map above 
>>> KSEG0/1.  I not only need to map above that, but above 4GB 
>>> entirely!  I'll map the PAs into KSEG2, most likey, following the 
>>> example of the ARC port.
>>>
>>> So what I'm going to do is break out the AMD/Alchemy stuff from 
>>> evbmips into a new port "aumips".
>>>   
>>
>>
>> I don't think there's a need to move all the existing Alchemy eval board
>> support from out of evbmips.  For 64-bit paddr_t support, you can just
>> add something like:
>>
>>        options _MIPS_PADDR_T_64BIT
>>  
>>
> I thought about this, but I am concerned about this type being 
> different for userland bits.  It seems like there is only one userland 
> for evbmips, and having the size of paddr_t be different for 
> diffferent kernels might break some things (tools, etc.)
>
> If paddr_t is truly confined to the kernel and is not exposed to any 
> user applications, then it will work.
>
> I've also considered *not* changing paddr_t and instead just 
> localizing the larger types to the logic that wires down the 
> addresses.  For now I've gone the other way, but I might go back and 
> localize it.  Certainly, if we are going to remain in evbmips then I 
> think it is a good idea to try to minimize changes to the system types 
> like paddr_t.
>
>> to evbmips/conf/std.pb1000 (ignoring for now that the file should
>> probably be renamed to std.alchemy).  There may be issues with building
>> LKMs by doing this, but that's a bridge that can be crossed later.  I'm
>> also not sure that you should be wiring down TLBs like the ARC port
>> does.  The Au1 core has only 32 TLB entries, so it's not as if you want
>> to lower the general number available any more than you have too.
>>
>> I'm not sure if you're targetting the AMD/Alchemy Au1550 eval board
>> or an entirely new board.  Ignore the next few paragraphs if you're
>> targeting the DBAu1550. :-)
>>  
>>
> I'm targetting both the DBAu1550 (which is my bring up machine), and 
> will eventually have our own board design.  I fully realize that parts 
> of the design will be board-specific, but for the moment everything 
> I'm doing is generic to the Au1550 chip itself.  (And pretty much for 
> the Au1500 as well.)
>
>> If the board you're targeting is an SBC or thin-client type machine,
>> you'd create a new sub-port under evbmips.  The current evbmips PB1000
>> sub-port (again, that probably should be renamed to ALCHEMY as well)
>> is specifically for the AMD/Alchemy eval boards.  Maybe something like
>> evbmips/tadpole.
>>  
>>
> Yes.  But ideally I think a lot of the changes from our board to the 
> eval boards will be easily handled by a different kernel config.  The 
> main source files should all be the same, I think.
>
> In any case, whether our "tadpole" platform lives in a separate port 
> or in evbmips should not be a major concern, because I strongly doubt 
> that we will be putting *that* part of the code back into NetBSD.  (We 
> are likely to have some proprietary bootup logic, as well as other 
> bits that are not generally applicable.)
>
>> An example of a recently added SBC is the ARM TS7200 (under evbarm) and
>> a somewhat less recent example of a thin-client is the PowerPC Explora
>> (under evbppc).  Some other currently separate ports (such as algor and
>> sbmips) probably should be moved under evb* at some stage as they also
>> fit in this category.
>>  
>>
> Okay.  So it seems like the idea is that evbmips should be a catchall 
> for all of the various mips ports.
>
>> If the board you're targeting is more or less a standalone computer,
>> then that would probably be enough to justify a completely new port.
>> However, that new port wouldn't be "aumips" but something along the
>> board/model name of your port.  Without knowing more about your target,
>> "tadpolemips" or "autadpole" something similar, given that there are
>> other sorts of tadpoles available with different CPUs.
>>  
>>
> Yes, we could do that.  But my intent is not to have a full port, 
> because I don't think I need one.  The only truly unique part of our 
> kernel will probably be the bits around the booting logic.  (We may or 
> may not use yamon.)
>
>> The ARC port you've already mentioned is an example of a "normal"
>> standalone computer, and thus has its own port.
>>
>>  
>>
>>> I'm also going to move the alchemy specific logic from mips/alchemy 
>>> to the aumips directory.  Hopefully this cleanup will make it easier 
>>> to see what is going on.
>>>   
>>
>>
>> The way the arch directories are structured is that any CPU specific
>> support is under arch/mips and any board/port specific support is under
>> arch/<machine-name>.
>>
>> By doing this, multiple different machines can use the same CPU support.
>> If, for example, a new game console called (for example) the frobnitz
>> were to be based on an Alchemy CPU, it would possibly live under
>> arch/frobnitz but use the shared Alchemy support from arch/mips/alchemy.
>>  
>>
> Okay, perhaps I was too hasty in moving this.  I may have been 
> confused about the delineation between "port" and "processor".  I 
> would have thought that a "port" would be to a processor, and that 
> most of the other details (IO, address maps, IRQs etc.) would be 
> handled by configuration files.
>
>>  
>>
>>> Of course, whether or not any of this gets committed to 
>>> NetBSD-current is unclear at this time.  I hope that once I have 
>>> pretty much the full Au1550 (and probably also the Au1500) going, 
>>> that I can get the stuff committed.  I'm going to try to do it in a 
>>> way that localizes "board-specific" changes to the configuration 
>>> files, since otherwise these SoCs all have pretty much the same 
>>> stuff on them.
>>>   
>>
>>
>> You mentioned (I think) that USB was broken?  It works on at least
>> the Au1000 and Au1500, and I thought the USB controller on the Au1550
>> was the same.  You may have some board specific problem rather than a
>> general Au1xxx USB problem there.
>>  
>>
> It doesn't work on the Au1550.  It complains about a bad OHCI 
> version.  I don't have an Au1500 to test it with.  (I did fix the 
> address and interrupt mappings for this, because they are different on 
> the Au1550.)
>
>    -- Garrett
>
>> Cheers,
>> Simon.
>> -- 
>> Simon Burge                                   <simonb@wasabisystems.com>
>> NetBSD Development, Support and Service:   http://www.wasabisystems.com/
>>  
>>