[parisc-linux] /usr/conf/machine header files

[parisc-linux] /usr/conf/machine header files

[Grant Grundler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=X-roman8, Size: 1273 bytes --]

Hi all,
This started with the search for IODC return data. IODC data is
"documented" in the header file /usr/conf/machine/cpu.h. This is
on both 10.20 and 11.00 HP-UX.  Look for real_IODC_data. And remember
the bit fields are allocated from "left to right" (MSB is bit 0).


This directory seems to be a gold mine of information about hardware.
I happened to look into /usr/conf/machine/save_state.h and found:
 *      There are three kinds of PA-RISC computer:
 *
 *      PA-RISC 1.0 (sometimes called PA83)
 *              32-bit integer registers with 16 64-bit floating point
 *              registers.  No Series 700 is a PA 1.0 machine and only a
 *              few models of the oldest Series 600 and 800 machines are
 *              PA 1.0.
...

Anyone interested in context switching though might find this
*very* interesting reading...Other interesting files are:

   File     Example
   -------- ----------------
   boot.h   /* Parameters exchanged between kernel loader and the kernel    */
   cpu.h    real_IODC_data and Module type numbers
   eeprom.h eg MIRAGE_EEPROM_BASE_ADDR is defined here
   eisa.h   Sversion for snakes/WAX EISA and EISA system board ids
   frame.h  Assembly Language Offsets for Argument or Stack Pointer
...


Happy Hunting!

grant

Re: [parisc-linux] /usr/conf/machine header files

[Philipp Rumpf]

> This directory seems to be a gold mine of information about hardware.

One extremely interesting piece of information for those interested in the
PA2.0 port:  64-bit virtual addresses are 42 bits per quadrant only and
start at the smallest address in the quadrant - so unlike alpha where the
addresses are "sign-extended".

	Philipp Rumpf

Re: [parisc-linux] /usr/conf/machine header files

[Grant Grundler]

Philipp Rumpf wrote:
> > This directory seems to be a gold mine of information about hardware.
> 
> One extremely interesting piece of information for those interested in the
> PA2.0 port:  64-bit virtual addresses are 42 bits per quadrant only and
> start at the smallest address in the quadrant - so unlike alpha where the
> addresses are "sign-extended".

Actually, HP-UX does sign extend I/O addresses. I'm not sure
if this is a feature of HP-UX or something in the HW makes it
easier to do it this way...anyone know?

Secondly, don't make assumptions about how many bits are used in
a virtual or physical addresses unless it's processor specific code.
(eg TLB handler or trap handler or hpmc handler). I know the number
of physical bits supported by the processor is going to increase
from 40-bits (runway).

cheers,
grant

Grant Grundler
Unix Developement Lab
+1.408.447.7253

Re: [parisc-linux] /usr/conf/machine header files

[Philipp Rumpf]

> > PA2.0 port:  64-bit virtual addresses are 42 bits per quadrant only and
> > start at the smallest address in the quadrant - so unlike alpha where the
> > addresses are "sign-extended".
> Actually, HP-UX does sign extend I/O addresses. I'm not sure

That's physical addresses though, so we really don't care, do we ?

> if this is a feature of HP-UX or something in the HW makes it
> easier to do it this way...anyone know?
> 

> Secondly, don't make assumptions about how many bits are used in
> a virtual or physical addresses unless it's processor specific code.
> (eg TLB handler or trap handler or hpmc handler). I know the number
> of physical bits supported by the processor is going to increase
> from 40-bits (runway).

physical addresses you are right about;  we really should use an unsigned
long for those and never expect them to be less than 64 bits in length.

virtual addresses, unfortunately, aren't as simple:  The 32 LSBs of the
space identifier get ORed into the 32 MSBs of the virtual address, so we
are limited to 2+(62-virtual_address_bits_used) effective bits for space
identifiers (on PA2.0 CPUs with 32 bit space registers).  As we want to
use at least one space identifier per process, actually using only 42
bits of the virtual address gives us 22 bits of space identifiers - or
1 M processes even if we use 4 space identifiers per process.

	Philipp Rumpf

Re: [parisc-linux] /usr/conf/machine header files

[Jerry Huck]

> From parisc-linux-request@thepuffingroup.com Wed Dec  8 21:05:46 PST 1999
> Date: Thu, 9 Dec 1999 05:06:34 +0100
> From: Philipp Rumpf <Philipp.H.Rumpf@mathe.stud.uni-erlangen.de>
> To: Grant Grundler <grundler@cup.hp.com>
> Cc: Philipp Rumpf <Philipp.H.Rumpf@mathe.stud.uni-erlangen.de>,
>         parisc-linux@thepuffingroup.com
> Subject: Re: [parisc-linux] /usr/conf/machine header files

> > > PA2.0 port:  64-bit virtual addresses are 42 bits per quadrant only and
> > > start at the smallest address in the quadrant - so unlike alpha where the
> > > addresses are "sign-extended".
> > Actually, HP-UX does sign extend I/O addresses. I'm not sure
> 
> That's physical addresses though, so we really don't care, do we ?

FYI,  More precisely, PA2.0 expects to be programmed with "F" extended
62-bit physical addresses.  The upper 2 bits are always ignored.  The
"F" extension is preserved in all processor resources independent of
the implemented addess space.  For example, a data reference to the
physical address 0x3FFF FFFF FFFF 0000 (PSW.d == 0) that took a TLB
miss would include the unimplemented bits in the ISR.

The one exception is the LPA instruction.  It is only defined to the
width of the implemented physical address space.  To convert that
address to a generic 64-bit pointer use:

    trialphysaddr = LPA(va);
    if( trailphysaddr == 0 ) /* do something else */
    physaddrwidth = PDC_MODEL.returnCPU_ID.ret[1] + 40;
    if( (trialphysaddr >> physaddrwidth) == 0xF) {
        /* need to F extend and decide what to put
           into the upper 2 bits */
        <...>
    } else
        physaddr = trialphysaddr;

The upper bits of the LPA result beyond the implemented boundary are
guaranteed to be zero.

All this discussion is only relevant to 2.0 processors running
the kernel in wide mode.

> > if this is a feature of HP-UX or something in the HW makes it
> > easier to do it this way...anyone know?

F extension reflects the architecture separation of I/O (uncached)
addresses from memory (cached) addresses.  The processor makes many
assumptions and address space is assigned to reflect this
architecture.  By allocating memory address space up from 0, and I/O
address space down from 0x3fff ffff ffff ffff, then all code is
independent of the implemented address space size.  I imagine other
approaches can do this but it works nicely for PA.

> > Secondly, don't make assumptions about how many bits are used in
> > a virtual or physical addresses unless it's processor specific code.
> > (eg TLB handler or trap handler or hpmc handler). I know the number
> > of physical bits supported by the processor is going to increase
> > from 40-bits (runway).
> 
> physical addresses you are right about;  we really should use an unsigned
> long for those and never expect them to be less than 64 bits in length.
> 
> virtual addresses, unfortunately, aren't as simple:  The 32 LSBs of the
> space identifier get ORed into the 32 MSBs of the virtual address, so we
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
More precisely: "into the upper 30 bits of the offset".  The upper two
space select bits are not included in the global virtual address.

> are limited to 2+(62-virtual_address_bits_used) effective bits for space
> identifiers (on PA2.0 CPUs with 32 bit space registers).  As we want to
> use at least one space identifier per process, actually using only 42
> bits of the virtual address gives us 22 bits of space identifiers - or
> 1 M processes even if we use 4 space identifiers per process.

Yes, and this division between space bits and offset bits are
flexible.  You could define a large number (say 2^28) spaces for
objects that won't be greater than 2^32 bytes in size.  ie. All 32-bit
applications and the 64-bit application's text segments.  Allocate the
remainder of the spaces as you indicate.  Another possibility is
consider having one 2^60 sized space for the OS and all straight
forwardly shared objects.  You get the following assignment of for
32-bit wide space IDs:
   0000 0000:   one 2^60 byte in size object
   1xxx xxxx:   2^28 in count 2^32 byte in size objects
   2xxx x000:   2^16 in count 2^44-byte in size objects
   3xxx x000:   2^16 in count 2^44-byte in size objects
   ...

You get the idea.
Jerry

Re: [parisc-linux] /usr/conf/machine header files

[Philipp Rumpf]

> FYI,  More precisely, PA2.0 expects to be programmed with "F" extended
> 62-bit physical addresses.  The upper 2 bits are always ignored.  The

The architecture documentation is quite explicit in that the 2 msbs get
ignored in the _virtual_ address offset generation only.  Actual CPUs
are quite likely to always ignore them, though.

> "F" extension is preserved in all processor resources independent of
> the implemented addess space.  For example, a data reference to the
> physical address 0x3FFF FFFF FFFF 0000 (PSW.d == 0) that took a TLB
> miss would include the unimplemented bits in the ISR.

How can you take a (Data, I assume) TLB miss with the PSW's D bit == 0 ?

> The one exception is the LPA instruction.  It is only defined to the
> width of the implemented physical address space.  To convert that
> address to a generic 64-bit pointer use:
> 
>     trialphysaddr = LPA(va);
>     if( trailphysaddr == 0 ) /* do something else */
>     physaddrwidth = PDC_MODEL.returnCPU_ID.ret[1] + 40;
>     if( (trialphysaddr >> physaddrwidth) == 0xF) {
>         /* need to F extend and decide what to put
>            into the upper 2 bits */
>         <...>
>     } else
>         physaddr = trialphysaddr;
> 
> The upper bits of the LPA result beyond the implemented boundary are
> guaranteed to be zero.

Why would we want to use LPA anyway ?

> > > if this is a feature of HP-UX or something in the HW makes it
> > > easier to do it this way...anyone know?
> 
> F extension reflects the architecture separation of I/O (uncached)
> addresses from memory (cached) addresses.  The processor makes many
> assumptions and address space is assigned to reflect this
> architecture.  By allocating memory address space up from 0, and I/O
> address space down from 0x3fff ffff ffff ffff, then all code is
> independent of the implemented address space size.  I imagine other
> approaches can do this but it works nicely for PA.

That's just not what the documentation says, and I propose we follow
it by simply using physical addresses 0xfXXX XXXX XXXX XXXX when
referring to IO space.

> > > Secondly, don't make assumptions about how many bits are used in
> > > a virtual or physical addresses unless it's processor specific code.
> > > (eg TLB handler or trap handler or hpmc handler). I know the number
> > > of physical bits supported by the processor is going to increase
> > > from 40-bits (runway).
> > 
> > physical addresses you are right about;  we really should use an unsigned
> > long for those and never expect them to be less than 64 bits in length.
> > 
> > virtual addresses, unfortunately, aren't as simple:  The 32 LSBs of the
> > space identifier get ORed into the 32 MSBs of the virtual address, so we
>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> More precisely: "into the upper 30 bits of the offset".  The upper two
> space select bits are not included in the global virtual address.

Right, thanks for the clarification.

> objects that won't be greater than 2^32 bytes in size.  ie. All 32-bit
> applications and the 64-bit application's text segments.  Allocate the
> remainder of the spaces as you indicate.  Another possibility is
> consider having one 2^60 sized space for the OS and all straight
> forwardly shared objects.  You get the following assignment of for
> 32-bit wide space IDs:
>    0000 0000:   one 2^60 byte in size object
>    1xxx xxxx:   2^28 in count 2^32 byte in size objects
>    2xxx x000:   2^16 in count 2^44-byte in size objects
>    3xxx x000:   2^16 in count 2^44-byte in size objects
>    ...

Indeed I didn't think about having spaces of different sizes before, and
it definitely makes sense to have one 2^62 byte space to map physical
memory / I/O with.

	Philipp Rumpf

Re: [parisc-linux] /usr/conf/machine header files

[Jerry Huck]

> Date: Sat, 11 Dec 1999 14:51:07 +0100
> From: Philipp Rumpf <Philipp.H.Rumpf@mathe.stud.uni-erlangen.de>
> To: huck@cup.hp.com
> Cc: parisc-linux@thepuffingroup.com
> Subject: Re: [parisc-linux] /usr/conf/machine header files

> > FYI,  More precisely, PA2.0 expects to be programmed with "F" extended
> > 62-bit physical addresses.  The upper 2 bits are always ignored.  The
           ^^^^^^^^ should be "absolute"

> The architecture documentation is quite explicit in that the 2 msbs get
> ignored in the _virtual_ address offset generation only.  Actual CPUs
> are quite likely to always ignore them, though.

My statement was wrong.  I forgot about our subtle distinction between
absolute and physical addresses and the contradictions in the 2.0 book.

Readers can skip the remainder of this note if your not interested in
address definitions.

The 1.x books made physical and absolute addresses equivalent.  The 2.0
architecture made a significant distinction between absolute and physical
addresses but did not properly document the difference.

Page 3-1, section "Physical and Absolute addressing", correctly defines
the two terms.  Basically, an absolute address is only 62-bits in
width and the upper 2 bits must be ignored.  Physical addresses are 64-bits
wide.  Page H-10 correctly describes the mapping between the two addresses.

The address you form for data or instruction addresses when PSR.D or
PSR.C (respectively) is zero is an ABSOLUTE address.  The LDWA and
STWA instructions specify an ABSOLUTE address.  This is consistently
correct in the book.

Inconsistently specified is the output of the TLB.  TLBs translate
virtual addresses to PHYSICAL addresses (full 64-bits).  This is
incorrect in many places.

Also, the discussion on page 3-8 on "Absolute Addresses" is confusing
since the upper 2 bits of the "offset" (a 64-bit quantity) is ignored
and all the memory vs. I/O distinction is done using the upper 4 bits
of the 62-bit absolute address.

So, you can still count on the interesting equivalent mapping that
is possible between absolute addresses and virtual addresses.

> > "F" extension is preserved in all processor resources independent of
> > the implemented addess space.  For example, a data reference to the
> > physical address 0x3FFF FFFF FFFF 0000 (PSW.d == 0) that took a TLB
> > miss would include the unimplemented bits in the ISR.
> 
> How can you take a (Data, I assume) TLB miss with the PSW's D bit == 0 ?

My mistake - bad example and incorrect terminology.  How about:

For example, a data reference to the absolute address 
0x3FFF FFFF FFFF 0000 (PSW.d == 0) that took an "assist emulation trap"
would include the unimplemented bits in the ISR.

> > The one exception is the LPA instruction.  It is only defined to the
> > width of the implemented physical address space.  To convert that
> > address to a generic 64-bit pointer use:
> > 
> >     trialphysaddr = LPA(va);
> >     if( trailphysaddr == 0 ) /* do something else */
> >     physaddrwidth = PDC_MODEL.returnCPU_ID.ret[1] + 40;
> >     if( (trialphysaddr >> physaddrwidth) == 0xF) {
> >         /* need to F extend and decide what to put
> >            into the upper 2 bits */
> >         <...>
> >     } else
> >         physaddr = trialphysaddr;
> > 
> > The upper bits of the LPA result beyond the implemented boundary are
> > guaranteed to be zero.
> 
> Why would we want to use LPA anyway ?

I don't know how Linux works, but it is a fast way to get the physical
address for DMA (say out of a virtually mapped buffer pool).  We have
used physically indexed tables that low-level handlers can quickly
pick up some information for fault handling (say some kind of page
promotion information or other things that don't fit in the TLB
entry).
> 
> > > > if this is a feature of HP-UX or something in the HW makes it
> > > > easier to do it this way...anyone know?
> > 
> > F extension reflects the architecture separation of I/O (uncached)
> > addresses from memory (cached) addresses.  The processor makes many
> > assumptions and address space is assigned to reflect this
> > architecture.  By allocating memory address space up from 0, and I/O
> > address space down from 0x3fff ffff ffff ffff, then all code is
> > independent of the implemented address space size.  I imagine other
> > approaches can do this but it works nicely for PA.
> 
> That's just not what the documentation says, and I propose we follow
> it by simply using physical addresses 0xfXXX XXXX XXXX XXXX when
> referring to IO space.

The documentation is a little inconsistent.  I was referring to
absolute addresses.  Depending on how you want to manage the possible
equivalent mappings, those upper 2 bits of absolute addresses will get
set to some interesting values.  Addresses used by I/O devices are
physical addresses and will definitely start with 0xF.

Jerry

...stuff deleted...

> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 
>