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
next prev parent 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