[OpenBIOS] [RFC PATCH 2/2] implement /uni-n node

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Feb 26 01:01:42 CET 2013

On 24/02/13 00:24, Amadeusz Sławiński wrote:

> it is required by xnu to boot on newworld machines
> there are still two thing to investigate
> 1. reg property, seems to have different size on real machine than in qemu
> http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/dev-trees-html/g4_agp_500_2.html
> 0x01000000 vs 0x00001000

In Core99.cpp I see these lines here:

   uniNBaseAddressTemp = ((unsigned long *)tmpData->getBytesNoCopy())[0];
   uniNBaseAddress = (unsigned long *)ml_io_map(uniNBaseAddressTemp, 

This implies that only the first 0x1000 bytes of the /uni-n bus device 
are mapped to the virtual address in reg (0xf8000000) and hence all of 
the control registers must lie within those boundaries.

Looking at 
for the uni-n at f8000000/i2c at f8001000 device suggests that child devices 
under /uni-n are mapped at offsets from 0x1000 onwards. Given that the 
code only looks for the power-mgmt node, then potentially you may be 
able to get away with having the size as 0x1000 if there actually no 
child nodes. PearPC may give you some clues here.

> 2. which value to put in device-rev property
> According to
> http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/Core99.h
> there are 3 possible values 3, 7, 10 and depending on them kernel takes different codepaths just look for "kUniNVersion" in:
> http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/Core99.cpp

Again I'd also have a look at PearPC source, but I guess the general 
rule is to have a look at the QEMU source and see if the device exists 
there and what registers are implemented - for example looking at how it 
calculates the shift for the kUniNArbCtrlQAckDelay register should give 
a good clue.



More information about the OpenBIOS mailing list