Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@dsl2.external.hp.com>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] FB on c3k
Date: Sat, 09 Mar 2002 23:56:41 -0700	[thread overview]
Message-ID: <20020310065641.D8D3A48EB@dsl2.external.hp.com> (raw)
In-Reply-To: Message from Thomas Bogendoerfer <tsbogend@alpha.franken.de> of "Thu, 07 Mar 2002 11:03:39 +0100." <20020307110339.A1590@solo.franken.de>

Thomas Bogendoerfer wrote:
> after sleeping over the problem, I believe we were short just one bit.
> We extracted 32 bits from the PTE. The lower 5 bits are zeroed and will
> be the 4 size bits and the one 0 bit in the TLB. That leaves 27 bits for
> the physical page number. Adding the 12 offset bits for 4k pages gives us
> just 39 bits, but we need 40. So instead of the change 32 -> 52 a
> change from 32 -> 33 should do the same. On the other side using all
> bits shouldn't matter and we are prepared for 44 bit and more.

ok. that all make sense now.
It made more sense when I read about extru and idtlbt in the 
PA 2.0 Arch book.

> BTW.
> isn't our current PDC space expansion wrong for "odd" sized address
> spaces ? It should work for 48 and 56, but not for anything else.
> Or do I miss something ?

I have no clue. jsm or willy know?

> I will have a J6700 at Cebit to play with, but I don't think I'll
> get spare time in the next couple of days.

Done! See ftp://ftp.p-l.o/patches/entry.S-diff

The 32-bit kernel with FB is working with 4 instances of the following
change to entry.S (all immediately preceed an idtlbt instruction):
-       extrd,u         pte,56,25,pte
+       extrd,s         pte,56,25,pte   /* bit 31:8 >> 8  */
+       depdi           0,3,4,pte       /* page_size = 4k (in case signed) */

CAVEAT: This is better than the brokeness we had before.
But it doesn't properly handle 0xf0xxxxxx addresses.
Those need to be "f-extended" with 0xf0f0f0... instead of all 1's.

> yes,  with your last ioctl32 changes. I need to recheck my first entry.S
> hack for the narrow mode pa2.0 tlb handler. I think my assembler code
> just sucks and setting up the tlbs the same way as for wide mode,
> should get us X with 32-bit kernels, too.

Done. patch on ftp.p-l.o/patches/entry.S-diff.
Can someone with VM cluefulness review this for me?

It seems to be working on my c3k with Vis-EG/PCI now though...wohoo! :^)

thanks,
grant

  reply	other threads:[~2002-03-10  6:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-06  8:01 [parisc-linux] FB on c3k Grant Grundler
2002-03-06 23:22 ` Thomas Bogendoerfer
2002-03-07  7:31   ` Grant Grundler
2002-03-07 10:03     ` Thomas Bogendoerfer
2002-03-10  6:56       ` Grant Grundler [this message]
2002-03-07 14:00     ` Carlos O'Donell Jr.
     [not found] <Pine.LNX.4.44.0203061421250.17588-100000@sal.ucc.ie>
2002-03-06 16:46 ` Grant Grundler
2002-03-06 22:19   ` M. Grabert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020310065641.D8D3A48EB@dsl2.external.hp.com \
    --to=grundler@dsl2.external.hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox