Re: G4 Macintosh - what is located at Real Address 0x80000000 ?

Tinkerer Atlarge <tinkerer@xxxxxxxxxxxxxxx> wrote:

Does anyone know what hardware on a G4 Macintosh decodes to the (hex)
80000000 - 9c000000 range?

I have no trouble matching the following output of the .translations
command to the bus addresses listed as "unit numbers" in the device tree
EXCEPT for the range mentioned above. The only clue I could find about
what might be there is frame-buffer-adr = 9c008000. The block diagram of
the computer shows an ATI graphics chip with its own dedicated 32MB ram
(size 02000000 bytes hex) which is nowhere near big enough to account
for all that physical address space. (The ATI chip and associated
hardware is located within node /pci@f0000000, also known as the agp
bus.)

Here is what ".translations" outputs on my G4 eMac:

0 > .translations
Virtual = 00000000 Size = 00003000 Physical = 00000000 Mode = 10
Virtual = 80000000 Size = 00080000 Physical = 80000000 Mode = 28
Virtual = 80080000 Size = 00001000 Physical = 80080000 Mode = 28
Virtual = 80081000 Size = 00001000 Physical = 80081000 Mode = 28
Virtual = f0000000 Size = 00010000 Physical = f0000000 Mode = 28
Virtual = f0800000 Size = 00001000 Physical = f0800000 Mode = 28
Virtual = f0c00000 Size = 00001000 Physical = f0c00000 Mode = 28
Virtual = f2000000 Size = 00010000 Physical = f2000000 Mode = 28
Virtual = f2800000 Size = 00001000 Physical = f2800000 Mode = 28
Virtual = f2c00000 Size = 00001000 Physical = f2c00000 Mode = 28
Virtual = f4000000 Size = 00010000 Physical = f4000000 Mode = 28
Virtual = f4800000 Size = 00001000 Physical = f4800000 Mode = 28
Virtual = f4c00000 Size = 00001000 Physical = f4c00000 Mode = 28
Virtual = f5000000 Size = 00001000 Physical = f5000000 Mode = 28
Virtual = f5200000 Size = 00200000 Physical = f5200000 Mode = 28
Virtual = f5200000 Size = 00200000 Physical = f5200000 Mode = 28
Virtual = f8000000 Size = 00003000 Physical = f8000000 Mode = 28
Virtual = ff800000 Size = 00400000 Physical = 1fc00000 Mode = 10
Virtual = fff04000 Size = 00002000 Physical = fff04000 Mode = 28
Virtual = fff06000 Size = 00002000 Physical = fff06000 Mode = 28 ok

It is easy to work out that addressable ram is represented by the lines
ending in "Mode = 10" and the io devices are the ones ending with "Mode
= 28". (Because only the lines with Mode = 10 have their addresses
actually translated, and I remember reading somewhere that address
translation is only enabled for access control, not address translation
for i/o devices, rom code being copied to ram prior to execution).

The first line represents the first block of ram used for the Exception
Vectors etc at Real AND Virtual Address 0-3000 (zero displacement
because the cpu disables address translation when responding to
exceptions - extra clues are in the /memory node). The third-last line
is the top 4MB (hex 00400000 bytes) of the 512MB Physical Ram
(size=20000000 hex) housing Open Firmware which appears at Virtual
Addresses ff800000-ffbfffff. All this is consistent with the /memory
node properties which list which parts of physical ram are already in
use, and how much remains available for other purposes like booting an
operating system.

The only thing which doesn't emerge from all these figures is what is
located at the halfway mark in the cpu's 4GB physical address space.

That last observation could be relevant because I vaguely recall reading
in some legacy powerpc doc that the OS (I can't remember whether
specific to MacOS or not) could not be allowed more than 2GB of RAM,
which also happens to be the maximum amount which can be installed in an
eMac.

Any insights, even vaguely remembered ones, about what might be located
at Real Addresses 80000000-9c000000 on a New World Macintosh would be
much appreciated.

Actually it's a 1 GB maximum which can be installed in an eMac. I have
heard of other G4 Macs which take more, but I don't know if Apple ever
made one which takes the full 2 GB.

Anyway I have solved the mystery in case anyone is interested. Some
hardware controllers come with their own memory buffers which need to be
accessed by the cpu. When the hardware is being initially set up, a
device can request a block of physical addresses in the cpu's address
space, thereby adding its buffer to the computer's physical memory map.
There is no requirement for such assignments to be featured in the
device tree or even to have virtual addresses assigned to them in every
case. These physical addresses don't normally change after the hardware
has been initialized, and are sometimes guaranteed not to change from
one startup to the next.

The devices responding to the unfamiliar addresses queried above can be
established and their exact purpose further investigated by entering the
following commands at the Open Firmware prompt:

dev pci1 mem-addr-base .
dev usb1 hc-base .
dev usb0 hc-base .
.

Relevant Pages

  • G4 Macintosh - what is located at Real Address 0x80000000 ?
    ... Does anyone know what hardware on a G4 Macintosh decodes to the (hex) ... It is easy to work out that addressable ram is represented by the lines ... translation is only enabled for access control, ...
    (comp.sys.mac.hardware.misc)
  • Re: Upgrade to WXP X64
    ... If you're using your old 32 bit applications, ... Page translation converts virtual addresses into physical addresses. ... The main benefit would seem to be, the ability to use more than 4GB of RAM. ... If you want to try the Windows 7 beta, ...
    (microsoft.public.windowsxp.general)
  • Re: DEFCON 16 and Hacking OpenVMS
    ... The PDP-11 did not do virtual address translation on a page by ... was a calculable fixed offset for the duration of a task. ... And if you had less than 64KB RAM, ... PDP-11 didn't even have APR. ...
    (comp.os.vms)
  • Re: Rethinking V.M.S
    ... As you stated, paging, swapping, related to disk I/O delay, ... I/O somehow to get the program into RAM). ... There aren't really cycles used up for address translation. ... And you still have to track working sets and the like unless you want ...
    (comp.os.vms)
  • Re: Input issues - key down with no key up
    ... > For the user the only thing that matters is that the keyboard works. ... Actually the spec is a standard and standard hardware performs as ... > Also disabling translation causes all kinds of obscure troubles. ...
    (Linux-Kernel)