[parisc-linux] PDC calls on the C3000

[parisc-linux] PDC calls on the C3000

[Matthew Wilcox]

I've been asked to explain what was going wrong with the PDC calls on
the C3000.  Here's what was going on:

        ldil            L%real_stack, 29        ; our stack pointer
        ldo             R%real_stack(29),29
        tophys          29

tophys is a macro which was doing:

	depi 0,1,2,gr

So the CPU was helpfully sign-extending the address of real_stack and
before the tophys macro was called we had the value
	0xffff'ffff'c0xx'xxxx
in r29.  The tophys macro was clearing the `c' to leave us with
	0xffff'ffff'00xx'xxxx
which would work if PDC recognised we were being called from narrow mode
(presumably PDC does on C360 hardware, or we wouldn't've had it working
on that machine).

I changed the tophys macro to:

	zdep gr, 31, 30, gr

which takes the rightmost 30 bits from the register, zeroes the whole
register and then stores them back into it:
	0xffff'ffff'c0xx'xxxx
becomes
	0x0000'0000'00xx'xxxx
and now PDC is happy, and so am I.

Re: [parisc-linux] PDC calls on the C3000

[Grant Grundler]

Matthew,
The hair on the back of my neck stood up when I read the second part...

Matthew Wilcox wrote:
...
> So the CPU was helpfully sign-extending the address of real_stack
...
> The tophys macro was clearing the `c' to leave us with
...
> which would work if PDC recognised we were being called from narrow mode
> (presumably PDC does on C360 hardware, or we wouldn't've had it working
> on that machine).

I'm thinking the inconsistency is possibly a firmware "bug" where either
the C360 or C3000 isn't behaving "right". Can anyone comment on what
the expected behavior is?


> I changed the tophys macro to:
> 
> 	zdep gr, 31, 30, gr
> 
> which takes the rightmost 30 bits from the register, zeroes the whole
> register and then stores them back into it:
> 	0xffff'ffff'c0xx'xxxx
> becomes
> 	0x0000'0000'00xx'xxxx
> and now PDC is happy, and so am I.

This is where the hair on the back of my neck went up.
The problem is on L-class and N-class machine we have
I/O and memory addresses which are > 4GB. And PDC will really
be confused on those platforms.

I wonder if the right answer is for the ldil instruction to NOT sign extend.
I don't know how to acheive that and I don't see us getting to L-class
without addressing that issue. I'm also hoping fixing this behavior will
make the firmware behavior differences (c360 vs C3000) irrelevant.

thanks,
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] PDC calls on the C3000

[Matthew Wilcox]

On Mon, Jan 17, 2000 at 10:02:59AM -0800, Grant Grundler wrote:
> I'm thinking the inconsistency is possibly a firmware "bug" where either
> the C360 or C3000 isn't behaving "right". Can anyone comment on what
> the expected behavior is?

I would class it as a bug, but I just needed a workaround for the
next month or two :-)  BTW, the same thing happens on mkp's J5000.

> > 	0xffff'ffff'c0xx'xxxx
> > becomes
> > 	0x0000'0000'00xx'xxxx
> > and now PDC is happy, and so am I.
> 
> This is where the hair on the back of my neck went up.
> The problem is on L-class and N-class machine we have
> I/O and memory addresses which are > 4GB. And PDC will really
> be confused on those platforms.

That won't be a problem.  The tophys macro is used to convert kernel
virtual addresses into physical addresses.  The kernel isn't going to
take more than 1GB of ram for its data segment :-)

We're not applying this macro to any other data type, don't worry.

Re: [parisc-linux] PDC calls on the C3000

[Alex deVries]

Grant Grundler wrote:
> > which takes the rightmost 30 bits from the register, zeroes the whole
> > register and then stores them back into it:
> >       0xffff'ffff'c0xx'xxxx
> > becomes
> >       0x0000'0000'00xx'xxxx
> > and now PDC is happy, and so am I.
> 
> This is where the hair on the back of my neck went up.
> The problem is on L-class and N-class machine we have
> I/O and memory addresses which are > 4GB. And PDC will really
> be confused on those platforms.

Right, and so we need access to wide mode registers for those PAT PDC
calls.  So I don't think we can do any of this until we have access to a
64 bit assembler.

In any case, this is not a priority right now.  I think we should only
be concerned with L class starting Feb. 7.  And N class isn't even on my
radar yet.

- Alex

-- 
Alex deVries
Director of Professional Services
The Puffins at Linuxcare