Re: anyone working on 64-bit PowerPC 970?

[Tim Kelly <hockey%dialectronics.com@localhost>]

At 11:41 AM -0800 1/17/05, Jeremy C. Reed wrote:
>What needs to be done? Who can do it?

I've been doing a lot of research on this, as part of a series of articles
documenting the process in which an operating system is loaded into memory,
interfaces with the hardware, and begins execution. The series is a bridge
between all of the documention on operating system design and on hardware
design, but little is published on making the two meet. IBM's
developerWorks has expressed interest in the entire series, and have agreed
to publish Part I and Part II of the series. If the response is positive,
they are interested in seeing the series to its final culmination, which is
to port NetBSD to a 970 based system. The entire series emphasizes the
PowerPC and NetBSD environments. Part I is nearing publication, as overall
the material is 99% complete but I've had to rewrite the article from
"article" format to "tutorial" template.

As for your first question, Matt Thomas has indicated that the (entire?)
pmap section has to be rewritten. I don't know the full extent of the
issues, but currently the VM uses Block Address Translation (BATs), which
are not present on the 970. The 970 uses "Segment Lookaside Buffers" (SLBs).

The 970 operates in 32 bit mode by default, so most executables should run
without compiling, but I am under the impression that some work on the
dynamic linker may have to be done, especially if both 32 bit and 64 bit
executables are going to be supported (swapping betweenthe two bit bit
modes is a matter of setting a bit). I haven't fully explored this area,
though, so this may be partially or completely incorrect. On the plus side,
apparently the ELF 64 standard will allow for Write XOR Execute (W^X),
which is not possible in a meaningful way with ELF 32.

True 64 bit applications need some additional compiler instructions, as
much like the 32 bit implementation can only load 16 bit words into
registers when adding (as opposed to retrieving a value in memory) and then
has to shift the value 16 bits before laoding another value (a constraint
imposed by the first 16 bits being op-code description of what instruction
and what register to use), the 64 bit implementation has to shift the
values 32 bits before loading another 32 bits. As I understand it, having
more than 4G of adress space would actually be useful to large databases
and the like.

I've had a bit of time (very, very briefly) with a G5, and there are
problems from the start with the bootloader. I did not have enough time to
identify them, and I was also having to work from session capture reports
sent back to me. I believe if I had time in front of one I could determine
the problem and overcome it. The bootloader does initialize a BAT, and the
problem was after this, but trying to load the kernel image into memory
failed.

>From there the new devices on the G5 have to be identified, and hopefully
matched to existing drivers.

>A member of my local BSD user group is interested in helping start a
>fund-raiser to help get this hardware supported.

If I had the financial resources, I would get the slowest dual processor
desktop Apple has available. While initially it may make sense to use an
iMac (note that the new Mac Mini uses a G4), for long term interests the DP
is better, for two reasons. First, Apple has a history of gutting the iMac
and iBook in the interest of keeping the price down. This often leads to
CPUs and other devices that aren't present anywhere else. Second, there is
clear indication that the PowerPC arch is moving toward dual and quad core
design, so the more effort behind supporting the DP with MP kernels the
better. As far as getting a top of the line desktop, the liquid cooled
design is showing signs of problems and if the device API is not well
fleshed out, it would not be beyond reason to think that running an
operating system without full support of the cooler would burn up the CPU.
I haven't spent any time looking at Darwin code to see if Apple has
released code to show the operation of the cooler; the APSL is not
compatible with BSD and blindly copying or following Apple's code is asking
for problems.

In a similar vein, through my contact at developerWorks I am working toward
getting IBM to release the code they shared with LinuxPPC64 under a BSD
license in addition to the GPL. There is precedence for IBM releasing code
under BSD, and we are hoping to use this precedence to convince the powers
that be at IBM that a dual license approach is in their best interest. IBM
moves slowly, though, and this gives some weight behind the above mentioned
series as an alternative method to get 970 based code under BSD.

tim