Alex Pelts | 1 Oct 01:19 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

I just glanced in my mips32 manual and I have seen there that just 
setting cpu to use 4K pages and modifying TLB entries correctly would 
give you access to 36 bit physical address space. I guess I was wrong on 
that one. Sorry if I caused confusion.

You would have to setup one TLB entry to access that space. Look at the 
code that sets up EntryLo0/EntryLo1 in netbsd tree. Unfortunately I an 
not familiar with the netbsd kernel, I am just a user of it ;).
PFN field of these registers is the physical address bits that you are 
looking for.

Thanks,
Alex

Garrett D'Amore wrote:
> Andrey Petrov wrote:
> 
>> On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
>>  
>>
>>> Thanks for the advice.  It looks like I need to change the size of 
>>> paddr_t, to accomodate a larger 36-bit value.  (The ARC port already 
>>> does this, though I don't know why it needs 64-bit values here.)
>>>
>>>   
>>
>>
>> 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 
(Continue reading)

M. Warner Losh | 1 Oct 07:20 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

In message: <051001024105.M0108147 <at> mirage.ceres.dti.ne.jp>
            Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> writes:
: In article <20050930.102636.104406435.imp <at> bsdimp.com>
: imp <at> bsdimp.com wrote:
: 
: > The Deskstation Tyne had similar contraints.  Its ISA bus was located
: > at 0x0900000000LL, for example.  sys/arch/arc/arc/wired_map.c has some
: > sample code.  Look at arc_enter_wired() there.  Then, in
: 
: Should we move these wired map functions into MI sys/arch/mips?
: ews4800mips may also requre them to map framebuffer at pa 0xf0000000
: in consinit() which is called before uvm_init()...
: 
: BTW, in this case maybe we should also adjust VM_MAX_KERNEL_ADDRESS
: accordingly (current arc doesn't do it though).

I think that might be a good idea.  Copying identical code that's
essentially the same on all MIPS of a given PTE type.

Warner

M. Warner Losh | 1 Oct 07:23 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

In message: <20050930183324.GA28951 <at> NetBSD.org>
            Andrey Petrov <petrov <at> NetBSD.org> writes:
: On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
: > Thanks for the advice.  It looks like I need to change the size of 
: > paddr_t, to accomodate a larger 36-bit value.  (The ARC port already 
: > does this, though I don't know why it needs 64-bit values here.)
: > 
: 
: 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 -)

You still need to map those addresses into a 32-bit address space
somehow.  You may need to do something special in the bus* functions
as well, but the basic mapping has to be there first.  Since PCI bus
acccesses are likely to be common, it likely makes good sense to
hard-wire a page of appropriate size to cover the PCI bus in the TLB.

Warner

Garrett D'Amore | 1 Oct 08:41 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

M. Warner Losh wrote:

>In message: <20050930183324.GA28951 <at> NetBSD.org>
>            Andrey Petrov <petrov <at> NetBSD.org> writes:
>: On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
>: > Thanks for the advice.  It looks like I need to change the size of 
>: > paddr_t, to accomodate a larger 36-bit value.  (The ARC port already 
>: > does this, though I don't know why it needs 64-bit values here.)
>: > 
>: 
>: 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 -)
>
>You still need to map those addresses into a 32-bit address space
>somehow.  You may need to do something special in the bus* functions
>as well, but the basic mapping has to be there first.  Since PCI bus
>acccesses are likely to be common, it likely makes good sense to
>hard-wire a page of appropriate size to cover the PCI bus in the TLB.
>  
>
Yes.  And hence I've decided to create an aumips port that has a 
different paddr_t (it will be 64 bit).  I'm planning on borrowing as 
much of the logic for wiring this external space from the ARC port as I can.

I figure a single 16MB page for PCI configuration space, and then 
allocate the rest "on demand" as PCI functions need their addresses 
mapped.  I'll do it in 16MB chunks with the hope of reducing the number 
of mappings.  However, the framebuffer we are using is going to need a 
32MB chunk, so we're looking to see at least 4 of these 16MB pages wired.
(Continue reading)

Simon Burge | 12 Oct 15:30 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

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:

(Continue reading)

Garrett D'Amore | 12 Oct 17:26 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

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.
>>
(Continue reading)

Garrett D'Amore | 12 Oct 18:54 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

A few more comments below:

Simon Burge wrote:

>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 am aware of this.  I'm pretty sure I need to wire down at least one 
entry for the PCI configuration space.  (The IDSEL mapping on these 
machines uses one upper address line for each IDSEL pin, so the address 
space is huge.  Therefore I do the same as Linux and just remap the page 
when needed as part of my pci_conf_read/pci_conf_write logic.)

Right now I'm using 32MB entires (16MB pages) with the address map 
looking like this:

 * D0000000 - DFFFFFFF        PCI memory        (256 MB)
 * E0000000 - E1FFFFFF        PCI IO            (32 MB)
 * E2000000 - E3FFFFFF        PCI config space    (32 MB)
 * E4000000 - E7FFFFFF        PCMCIA IO        (64 MB)
 * E8000000 - EBFFFFFF        PCMCIA attribute space    (64 MB)
 * EC000000 - EFFFFFFF        PCMCIA memory        (64 MB)

The other spaces (apart from PCI config space) I only map on demand, so 
a small machine with only memory devices with small register spaces will 
only wire down two entries (one for PCI config and one for register access.)

(Continue reading)

Garrett D'Amore | 12 Oct 22:23 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

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:

(Continue reading)

Garrett D'Amore | 14 Oct 19:58 2005

Re: need advice regarding Au 1550 (MIPS) memory mapping

Okay, I have PCI working now, mostly.  (wi(4) doesn't work, because the 
bus_space_read_multi_stream() seems busted -- I don't understand it, but 
I'm getting scrambled data here -- not endian reversed, but almost as if 
caching is busted or somesuch.  I have work to do there.  Advice from 
anyone who's seem problems with wi(4) like this would be helpful.)

But ath(4) works fine.  So DMA, basic register access, and interrupt 
mapping seems to work.

Here's why we need a new port, though:

* paddr_t really does have to be 64-bit, I think, in order for mmap() to 
work properly for mmap() to work (needed for framebuffers).

* the bus_space_align_chipdep.c logic from the generic mips port is 
busted for little endian busses when the processor is running in 
big-endian mode.  And it lacks the bus_space_XXX_stream methods (it 
#define's them to the non-stream versions).

* having a new paddr_t seems to break some tools.  vmstat is busted 
right now, and my first guess is that this data structure is busted.  
Kernel grovelers will be busted as well.

So, my "aumips" port (maybe "alchemy" is a better name?) is going to 
remain apart from evbmips, for the time being.

Hopefully I'll be submitting patches back to netbsd before too long.

    -- Garrett

(Continue reading)

Garrett D'Amore | 15 Oct 17:52 2005

compile vs run-time dependencies?

I have a question:

The Alchemy parts I am working on (these are MIPS-based SoCs) have quite 
a few differences from one part to the next.  (Differences in what 
devices are available, where they are located, and in some cases 
differences in the details of certain registers for those devices.)

My question is whether to adjust to these differences based on 
compile-time #ifdef's and macros, or whether to include run-time checks 
based on the processor ID.

 From my perspective, there is little value in run-time checks for this, 
and frankly since a lot of the details can be handled by constant 
redefinitions in header files, compile-time checks will lead (I believe) 
to cleaner code.

The drawback is that you need different kernels for different SoCs.

As these parts not used in general purpose computers (that I'm aware of, 
at least), I don't see a lot of value in supporting a generic kernel 
that can port from one chip to another.  However, I invite comment on this.

(The current alchemy support does it at run-time, however, for a variety 
of reasons, I don't think this support is adequate for the Au1550 parts, 
and frankly, a lot of the details for some devices like AC'97 and PCI 
interrupt routing are board specific and cannot be determined at 
run-time anyway.)

Thanks!

(Continue reading)


Gmane