RE: Interrupt handling....

RE: Interrupt handling....

[Matthew Dharm]

Okay... I think I've got a problem that isn't covered by the usual
examples.

I'm now trying to implment a second-level interrupt demuxer.  My
exception handler, when it sees a certain bit set in the CP0_CAUSE
register set, attempts to read from the second-level controller.  The
problem is, that code looks like this:

	li	t0, 0xfc000000
	lb	t1, 0xc(t0)

Which, as you can see, attempts to access address 0xfc00000c.  And
then I get:

Unable to handle kernel paging request at virtual address fc00000c,
epc == 801af2ac, ra == 80102eb8
Oops in fault.c::do_page_fault, line 206:

I'm guessing I'm in trouble here.  My instincts tell me the the only
way out of this might be to add a wired TLB entry to make certain I
can always access physical address 0xfc00000c... but I'm hoping there
is a better solution than tying up a TLB entry like that.  After all,
isn't that what ioremap is supposed to do?

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> Sent: Thursday, August 29, 2002 1:46 PM
> To: Matthew Dharm
> Cc: Linux-MIPS
> Subject: Re: Interrupt handling....
>
>
> Matthew Dharm wrote:
> > I've taken it upon myself to re-write some interrupt
> handling code.
> > It's a mess, and it needs cleaning.
> >
>
> That is usually a right attitude to start ... :=)
>
> >
> > An interrupt handler must be registered with
> set_except_vector(0, ...)
> > which must return a numeric code in the range of
> 0..NR_IRQS -- it can
> > do this in any way it wants, including limited function calls (ie
> > there is a stack in place).
> >
>
> Interrupt is setup throught request_irq()/setup_irq().
> set_except_vector()
> for setting exception handlers, which is different from interrupts.
>
> > The irq_desc array of irq_desc_t structures is where the magic
> > happens.  The value returned by the interrupt handler is
> used as an
> > index into this array to do the dispatch a specific handler.  The
> > 'status' and 'action' fields are pretty much
> self-explanatory.  The
> > 'handler' field seems to point to a set of function
> pointers used for
> > enabling/disabling the IRQ.  But what is 'depth' for?
> Boards seem to
> > set it to either 0 or 1 commonly, but I don't see why.
>
> For nested disabling and enabling of interrupts.
>
> > I also don't
> > see how IRQ sharing is accomplished...
>
> Yes, it is there.  See do_IRQ() and a sub-routine
> handle_event() (or something
> like that)
>
>  > Is this pretty much how it all works?
>
> I have a more detailed description in my porting guide.
>
> http://linux.junsun.net/porting-howto/porting-howto.html#cha
pter-interrupt

Jun

RE: Interrupt handling....

[Dominic Sweetman]

Matthew,

> Okay... I think I've got a problem that isn't covered by the usual
> examples.

Possibly this is too simple an answer and is stuff you know quite well
already...

> Which, as you can see, attempts to access address 0xfc00000c.

But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
are always translated by the TLB, and you haven't got an entry.

Registers from things like the 2nd level interrupt controller are
memory mapped I/O locations, and you need to do an uncached access to
the appropriate physical address.

Most MIPS hardware has registers mapped between 0-512Mbyte
(0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
to that using the 'kseg1' window, which occupies the 

  0xa000.0000-0xbfff.ffff  (CPU virtual address)
  0x0000.0000-0x1fff.ffff  (physical address).

There are macros defined for translating a physical address into a
kseg1 address (just add 0xa000.0000, really).

You could read the book ("See MIPS Run")...

-- 
Dominic Sweetman, 
MIPS Technologies (UK) - formerly Algorithmics
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

RE: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Dominic Sweetman wrote:

> > Which, as you can see, attempts to access address 0xfc00000c.
> 
> But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> are always translated by the TLB, and you haven't got an entry.
> 
> Registers from things like the 2nd level interrupt controller are
> memory mapped I/O locations, and you need to do an uncached access to
> the appropriate physical address.

 As I understand 0xfc00000c is the physical address.  Thus you cannot
reach it via KSEG0/1 (although you may use XKPHYS to get there in the
64-bit mode).  Still ioremap() already handles the case mapping the area
requested in the KSEG2 space, so it should work just fine. 

> Most MIPS hardware has registers mapped between 0-512Mbyte
> (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
> to that using the 'kseg1' window, which occupies the 
> 
>   0xa000.0000-0xbfff.ffff  (CPU virtual address)
>   0x0000.0000-0x1fff.ffff  (physical address).

 As I understand this is an exception.  Possibly the system supports more
than 512MB of RAM and the designers wanted to avoid holes. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Interrupt handling....

[Matthew Dharm]

On Wed, Sep 04, 2002 at 02:58:26PM +0200, Maciej W. Rozycki wrote:
> On Wed, 4 Sep 2002, Dominic Sweetman wrote:
> 
> > > Which, as you can see, attempts to access address 0xfc00000c.
> > 
> > But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> > are always translated by the TLB, and you haven't got an entry.
> > 
> > Registers from things like the 2nd level interrupt controller are
> > memory mapped I/O locations, and you need to do an uncached access to
> > the appropriate physical address.
> 
>  As I understand 0xfc00000c is the physical address.  Thus you cannot
> reach it via KSEG0/1 (although you may use XKPHYS to get there in the
> 64-bit mode).  Still ioremap() already handles the case mapping the area
> requested in the KSEG2 space, so it should work just fine. 

This is the case.  The board itself has up to 1G of SDRAM.  Most of the
boards we sell have a minimum of 512MB.  So our I/O (PCI, external devices,
etc.) all have physical addresses in the high-end of the address space.

64-bit mode would be great... and we plan to go there eventually.  But, for
now, 32-bit is where we are.

> > Most MIPS hardware has registers mapped between 0-512Mbyte
> > (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
> > to that using the 'kseg1' window, which occupies the 
> > 
> >   0xa000.0000-0xbfff.ffff  (CPU virtual address)
> >   0x0000.0000-0x1fff.ffff  (physical address).
> 
>  As I understand this is an exception.  Possibly the system supports more
> than 512MB of RAM and the designers wanted to avoid holes. 

This is exactly the case.  Our organization focuses on high-end computing
platforms.  512MB is becoming a minimum amount of memory for us.

Matt

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: Interrupt handling....

[Dominic Sweetman]

Matthew Dharm (mdharm@momenco.com) writes:

> >  As I understand 0xfc00000c is the physical address.  Thus you cannot
> > reach it via KSEG0/1 (although you may use XKPHYS to get there in the
> > 64-bit mode).  Still ioremap() already handles the case mapping the area
> > requested in the KSEG2 space, so it should work just fine. 
> 
> This is the case.  The board itself has up to 1G of SDRAM.  Most of the
> boards we sell have a minimum of 512MB.  So our I/O (PCI, external devices,
> etc.) all have physical addresses in the high-end of the address space.

Well, next time, get your board designers to think before they map...

It's generally better to map some DRAM low (for boot ROMs and other
stupid programs you don't want to make big-address aware), then remap
the whole DRAM to some very high address for Linux.  Much better than
forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get
at I/O.

> 64-bit mode would be great...

Bear in mind that there *isn't a 64-bit mode*.  Privileged code (which
is everything except Linux applications) can always run 64-bit
instructions; all addresses are 64-bits really, it's just the
sign-extension of the registers which makes you think you've got
32-bit pointers.  Usually a 64-bit CPU can access XKPHYS any time
it can access I/O registers.

-- 
Dominic Sweetman, 
MIPS Technologies (UK) - formerly Algorithmics
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

Re: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Dominic Sweetman wrote:

> Well, next time, get your board designers to think before they map...
> 
> It's generally better to map some DRAM low (for boot ROMs and other
> stupid programs you don't want to make big-address aware), then remap
> the whole DRAM to some very high address for Linux.  Much better than
> forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get
> at I/O.

 Hmm, what's the deal?  Other processors always use MMU to access iomem...

> Bear in mind that there *isn't a 64-bit mode*.  Privileged code (which
> is everything except Linux applications) can always run 64-bit
> instructions; all addresses are 64-bits really, it's just the
> sign-extension of the registers which makes you think you've got
> 32-bit pointers.  Usually a 64-bit CPU can access XKPHYS any time
> it can access I/O registers.

 Well, it's mostly a programming convention.  Without going into details,
arch/mips is the 32-bit mode and arch/mips64 is the 64-bit one.  The usual
approximation is the state of cp0.kx, even though 64-bit operations do
indeed work when ~cp0.kx.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Interrupt handling....

[Matthew Dharm]

On Wed, Sep 04, 2002 at 10:53:55AM +0100, Dominic Sweetman wrote:
> 
> Matthew,
> 
> > Okay... I think I've got a problem that isn't covered by the usual
> > examples.
> 
> Possibly this is too simple an answer and is stuff you know quite well
> already...

Yeah, it is. See my response to Maciej's posting....

> > Which, as you can see, attempts to access address 0xfc00000c.
> 
> But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> are always translated by the TLB, and you haven't got an entry.

It's also the physical address.

And this is the heart of the problem.  I set up an ioremap, so I thought
that the TLB exception handler would fix this for me.  It looks like that
code won't do anything if the exception was generated from an interrupt...
Or am I reading it wrong?  I'm not an expert on the TLB code...

> You could read the book ("See MIPS Run")...

I read it quite some time ago.  My copy got very dog-eared before I had the
majority of the information committed to memory.  Nice book, BTW.

Matt

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Matthew Dharm wrote:

> And this is the heart of the problem.  I set up an ioremap, so I thought
> that the TLB exception handler would fix this for me.  It looks like that
> code won't do anything if the exception was generated from an interrupt...
> Or am I reading it wrong?  I'm not an expert on the TLB code...

 The kernel memory is unswappable so a PTE is always available.  If the
TLB refill handler cannot fetch it for some reason, then there is a bug
somewhere.  It might be helpful if you narrowed it down a bit -- refills
work correctly for modules, including interrupt handlers, and they reside
in KSEG2. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: Interrupt handling....

[Matthew Dharm]

Okay... What type of information do you need?

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
> Sent: Wednesday, September 04, 2002 10:03 AM
> To: Matthew Dharm
> Cc: Dominic Sweetman; Jun Sun; Linux-MIPS
> Subject: Re: Interrupt handling....
>
>
> On Wed, 4 Sep 2002, Matthew Dharm wrote:
>
> > And this is the heart of the problem.  I set up an
> ioremap, so I thought
> > that the TLB exception handler would fix this for me.  It
> looks like that
> > code won't do anything if the exception was generated
> from an interrupt...
> > Or am I reading it wrong?  I'm not an expert on the TLB code...
>
>  The kernel memory is unswappable so a PTE is always
> available.  If the
> TLB refill handler cannot fetch it for some reason, then
> there is a bug
> somewhere.  It might be helpful if you narrowed it down a
> bit -- refills
> work correctly for modules, including interrupt handlers,
> and they reside
> in KSEG2.
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
>

RE: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Matthew Dharm wrote:

> Okay... What type of information do you need?

 Well, first check if a PTE is indeed installed by ioremap() in the table. 
If so, the what happens at the access time -- what exceptions, what are
the contents of the related registers, what does exist in the TLB, etc.
You don't need to go to the IRQ handler at first -- it might be easier to
get such things if you deliberately access the location from elsewhere,
e.g. from the setup code right after ioremap().

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: Interrupt handling....

[Jon Burgess]

>    li   t0, 0xfc000000
>    lb   t1, 0xc(t0)
>
>After all,
>isn't that what ioremap is supposed to do?

I think the problem is that you need to use the pointer which ioremap() returns
to access the region you requested. It looks like you've assumed that ioremap()
will map it 1:1 which I don't think is the case.

i.e.

struct hw_regs *foo;

foo = (struct hw_regs *)ioremap(0xfc000000, <Size>);

foo->command = hw_reset;
...


     Jon