Uncacheable memory

Uncacheable memory

[Andrew Flach]

Hi all,

For some simple tests I would like to specify some regions of an application program as uncacheable. For example, the application contains a function that maps to the memory address space 0x08002000 to 0x0800A000 in the executable. When this program is run, code within this address space should be marked as uncacheable and the Kernel should not store any data between 0x08002000 and 0x0800A000 in the cache. Is there an straightforward way to do that? Could this be realised with the PAT or do I need to have a look at the MTTR?

Thanks
-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

[parisc-linux] uncacheable memory

[willy]

On Sat, Mar 04, 2000 at 09:49:49PM -0800, Grant Grundler wrote:
> HP systems have three I/O MMU's which are I/O coherent: U2/Uturn,
> Astro/Ike, and Epic/SAGA.  AFAIK, all systems using one on them have
> the processor(s) connected to a "Runway" bus.  This limits what
> processor model those systems can have: PA-7200, -8000, -8200, or -8500.
> 
> (Caveats:
>  - T-class has something similar to U2 which is NOT I/O coherent

According to the hwdb, the T600 has two `Java BC Summit Port (IOA)'.
And you're the only one in possession of a T-class :-).  All the devices
in the T600 seem to be special devices so the drivers would have to
be freshly written anyway.  I don't see a PCI adapter in the T-class,
can one be fitted?  I assume Summit is the name of a bus, like Runway
only different?

> In personal conversations, two knowledgable folks have suggested
> the following:
> o PA-7100LC systems support uncacheable memory and subcacheline access.
>   So these boxes should be supportable.

that's good, that's a fair chunk of those machines which people have (712,
725/100, 715/later, E-class, early D-class).

> o PA-7300LC systems *might* support uncacheable memory and subcacheline...
>   (Could anyone definitively answer this for any PA-7300LC box?)

According to the 7300LC ERS, section 1.1.2 (Integrated Caches and TLB)
`Uncached memory pages are supported via the TLB U-bit.'  Then section
1.2.2, (Differences from the PA7100LC) `Uncacheable pages are still
supported.  Note: PA7100LC did not require the U bit to be set on TLB
entries for I/O pages, but the PA7300LC does (this was always an
architural requirement).'

I think that's enough for us to go on.

> o PA-7000 systems are pretty much SOL.
>   (But they could be perfectly useful if folks add cache flushing to
>    the few device drivers needed for graphics and stuff off of LASI.)

how about PA7100/7150 systems?  (715/early, 735, 755, later Nova servers)
They will also need explicit cache flushing added, I guess.

Re: uncacheable memory

[Grant Grundler]

On Sat, Mar 04, 2000 at 09:49:49PM -0800, Grant Grundler wrote:
> HP systems have three I/O MMU's which are I/O coherent: U2/Uturn,
> Astro/Ike, and Epic/SAGA.  AFAIK, all systems using one on them have
> the processor(s) connected to a "Runway" bus.  This limits what
> processor model those systems can have: PA-7200, -8000, -8200, or -8500.
> 
> (Caveats:
>  - T-class has something similar to U2 which is NOT I/O coherent

Apologies. I should have been clearer about several things.

"T-class" should have been "T600".
I don't think T5xx series have any sort of I/O TLB in them.

willy@thepuffingroup.com wrote:
> According to the hwdb, the T600 has two `Java BC Summit Port (IOA)'.
> And you're the only one in possession of a T-class :-).

Actually, I'm neither in possession of one nor the only person who
might be. I couldn't believe it, but AFAIK HP sold thousands of them.
(The ioscan output is left over from my previous job.)
FTW, the URL is still valid but no longer linked from the
main "servers" web page:

	http://www.unixsolutions.hp.com/products/servers/tclass/

I suggest interested parties "snarf" what they can from those web pages
before the pages go away....375kg...sheesh.

> All the devices in the T600 seem to be special devices so the
> drivers would have to be freshly written anyway.  I don't see
> a PCI adapter in the T-class, can one be fitted?

First, T5xx only supports HP-PB devices. Basically same devices
as "Nova" (EFGHI-) class boxes and K-class. However, like K-class,
T600 also supports GSC cards in a "daughter board" form factor.
(but the "header" sheet metal is slightly different.... *SIGH*)

And HP does make/ship card-mode Dino 100BT cards for both T600
and K-class. Making card-mode Dino work on T600 is quite impossible
without looking at HP-UX source (or reverse engineering the binary).
I helped do it once. Java really doesn't like to play with Dino.

> I assume Summit is the name of a bus, like Runway only different?

Yes. AFIAK, Summit is the "memory" bus for T-5xx series.
On T600, same bus protocol but it's twice as "wide".


Someone else asked what's wrong with the memory controllers:

AFAIK, subcacheline accesses are a different type of transaction 
which many HP memory controllers don't *need* to support. I'm guessing
systems where I/O devices sit on the same bus as the memory controller
(eg 712, PA-7100LC), the memory controller supports all types of
transactions in order for DMA to work. So if the U-bit is also
supported by the processor, it'll all work.


hope this is better,
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253