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