[RFC PATCH 0/2] implement device nodes needed by xnu kernel

[Amadeusz Sławiński]

Following patches implement /uni-n and /pci/mac-io/via-cuda/power-mgt
With them xnu kernel no longer panics when recognizing machine type.

Amadeusz

[RFC PATCH 1/2] add power-mgt node under /pci/mac-io/via-cuda

[Amadeusz Sławiński]

xnu needs power-mgt node otherwise it panics
http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/C...

I see two possible locations
either /pci/mac-io/power-mgt
http://web.archive.org/web/20090107152212/http://penguinppc.org/historical/d...
or /pci/mac-io/via-cuda/power-mgt
http://web.archive.org/web/20090107144433/http://penguinppc.org/historical/d...

also seen it under /pci/pci-bridge/mac-io/via-pmu/power-mgt
http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/d...

Seems like it is basically used to fake powermanagement

Signed-off-by: Amadeusz Sławiński 
---
 arch/ppc/qemu/init.c |  6 ++++--
 drivers/cuda.c       | 15 +++++++++++++++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index a8fc320..5a11610 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -258,12 +258,14 @@ cpu_generic_init(const struct cpudef *cpu)
     push_str("icache-block-size");
     fword("property");

-    PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
+    //PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
+    PUSH(0x017c0f93);
     fword("encode-int");
     push_str("timebase-frequency");
     fword("property");

-    PUSH(fw_cfg_read_i32(FW_CFG_PPC_CPUFREQ));
+    //PUSH(fw_cfg_read_i32(FW_CFG_PPC_CPUFREQ));
+    PUSH(0x1dcd6500);
     fword("encode-int");
     push_str("clock-frequency");
     fword("property");
diff --git a/drivers/cuda.c b/drivers/cuda.c
index 3a57c7d..9555dea 100644
--- a/drivers/cuda.c
+++ b/drivers/cuda.c
@@ -369,6 +369,20 @@ rtc_init(char *path)

}

+static void
+powermgt_init(char *path)
+{
+	phandle_t ph;
+	char buf[64];
+
+        snprintf(buf, sizeof(buf), "%s/power-mgt", path);
+	REGISTER_NAMED_NODE(rtc, buf);
+
+	ph = find_dev(buf);
+	set_property(ph, "device_type", "power-mgt", 10);
+	set_property(ph, "compatible", "power-mgt", 10);
+}
+
 cuda_t *cuda_init (const char *path, phys_addr_t base)
 {
    cuda_t *cuda;
@@ -399,6 +413,7 @@ cuda_t *cuda_init (const char *path, phys_addr_t base)
 #endif

rtc_init(buf);
+	powermgt_init(buf);

main_cuda = cuda;

[RFC PATCH 1/2] add power-mgt node under /pci/mac-io/via-cuda

[Mark Cave-Ayland]

On 24/02/13 00:24, Amadeusz Sławiński wrote:
> xnu needs power-mgt node otherwise it panics
> http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/C...
>
> I see two possible locations
> either /pci/mac-io/power-mgt
> http://web.archive.org/web/20090107152212/http://penguinppc.org/historical/d...
> or /pci/mac-io/via-cuda/power-mgt
> http://web.archive.org/web/20090107144433/http://penguinppc.org/historical/d...
>
> also seen it under /pci/pci-bridge/mac-io/via-pmu/power-mgt
> http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/d...
>
> Seems like it is basically used to fake powermanagement

Agreed - it doesn't seem to matter particularly where the node lies, but 
I suppose it's a hint for the parent device. I'd compare the OpenBIOS 
device tree with the historical dev trees ("cd /" followed by 
"show-devs"), work out which Mac99 model is closest (hence being the 
model emulated by QEMU) and use that as a baseline.

HTH,

Mark.

[RFC PATCH 1/2] add power-mgt node under /pci/mac-io/via-cuda

[Programmingkid]

On Feb 25, 2013, at 7:11 PM, Mark Cave-Ayland wrote:
> On 24/02/13 00:24, Amadeusz Sławiński wrote:
> > xnu needs power-mgt node otherwise it panics
> > http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/C...
> >
> > I see two possible locations
> > either /pci/mac-io/power-mgt
> > http://web.archive.org/web/20090107152212/http://penguinppc.org/historical/d...
> > or /pci/mac-io/via-cuda/power-mgt
> > http://web.archive.org/web/20090107144433/http://penguinppc.org/historical/d...
> >
> > also seen it under /pci/pci-bridge/mac-io/via-pmu/power-mgt
> > http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/d...
> >
> > Seems like it is basically used to fake powermanagement
>
> Agreed - it doesn't seem to matter particularly where the node lies, but I suppose it's a hint for the parent device. I'd compare the OpenBIOS device tree with the historical dev trees ("cd /" followed by "show-devs"), work out which Mac99 model is closest (hence being the model emulated by QEMU) and use that as a baseline.
>
> HTH,
>
> Mark.

My own research indicates that the PowerMac1,1 is the model that is most similar to QEMU's model. Here is some information about that model: http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerMac1,1

According to Andreas Farber's research, the PowerMac1,1 doesn't have a uni-north node to begin with. It has instead a Grackle node. I suspect Mac OS X reads the incorrect value of PowerMac2,1 and tried to query for a uni-north node.

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

[Amadeusz Sławiński]

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/d...
0x01000000 vs 0x00001000

2. which value to put in device-rev property
According to
http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/C...
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/C...

Signed-off-by: Amadeusz Sławiński 
---
 arch/ppc/qemu/init.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index 5a11610..7f93d82 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -639,6 +639,56 @@ static void ffilll(void)
     }   
 }

+static void uni_n_init(void)
+{
+    push_str("/");
+    fword("find-device");
+
+    fword("new-device");
+    push_str("uni-n");
+    fword("device-name");
+
+    push_str("APPL,uninorth");
+    fword("encode-string");
+    push_str("model");
+    fword("property");
+
+    push_str("memory-controller");
+    fword("encode-string");
+    push_str("device_type");
+    fword("property");
+
+    push_str("uni-north");
+    fword("encode-string");
+    push_str("compatible");
+    fword("property");
+
+    PUSH(1);
+    fword("encode-int");
+    push_str("#address-cells");
+    fword("property");
+
+    PUSH(1);
+    fword("encode-int");
+    push_str("#size-cells");
+    fword("property");
+
+    PUSH(0xf8000000);
+    fword("encode-int");
+    PUSH(0x00001000); // XXX: check this on qemu is 0x1000 on net is 0x1000000
+    fword("encode-int");
+    fword("encode+");
+    push_str("reg");
+    fword("property");
+
+    PUSH(0);
+    fword("encode-int");
+    push_str("device-rev");
+    fword("property");
+
+    fword("finish-device");
+}
+
 void
 arch_of_init(void)
 {
@@ -908,4 +958,8 @@ arch_of_init(void)

bind_func("platform-boot", boot);
     bind_func("(go)", go);
+
+    if (is_newworld()) {
+        uni_n_init();
+    }
 }

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

[Mark Cave-Ayland]

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
> reg property, seems to have different size on real machine than in qemu
>
> http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/d...
> 0x01000000 vs 0x00001000

In Core99.cpp I see these lines here:

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

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 
http://web.archive.org/web/20090107151044/http://penguinppc.org/historical/d... 
for the uni-n@f8000000/i2c@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.
> which value to put in device-rev property
>
> According to
> http://www.opensource.apple.com/source/AppleCore99PE/AppleCore99PE-121.0.2/C...
> 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/C...

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.

HTH,

Mark.

[RFC PATCH 0/2] implement device nodes needed by xnu kernel

[Mark Cave-Ayland]

On 24/02/13 00:24, Amadeusz Sławiński wrote:
> Following patches implement /uni-n and /pci/mac-io/via-cuda/power-mgt
> With them xnu kernel no longer panics when recognizing machine type.
>
> Amadeusz

Hi Amadeusz,

Are you planning to resubmit this patchset as requested by Andreas?

ATB,

Mark.