This is the last news I can find on G5 support. Is there any more  
news, is anyone working on the port? This can be increasingly  
interesting with all the next generation game consoles using PPC as  
well.
-- 
Pelle Johansson

17 jan 2005 kl. 21.45 skrev Tim Kelly:

> 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
>
>
>