[Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Alexander Graf]

While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
over a few issues that prevented it from doing so.

With these patches applied I still can't properly boot Mac OS X with -M mac99,
but I get a lot further than before. The biggest issue that's left now is to
properly fake Mac OS X into believing our timebase frequency. If I hack up the
cuda timer I can successfully boot Mac OS X on mac99:

===========

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index ff6051d..3d40534 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -102,7 +102,7 @@
 #define CUDA_TIMER_TICKLE		0x24
 #define CUDA_COMBINED_FORMAT_IIC	0x25

-#define CUDA_TIMER_FREQ (4700000 / 6)
+#define CUDA_TIMER_FREQ ((4700000 / 6) / 64)
 #define CUDA_ADB_POLL_FREQ 50

 /* CUDA returns time_t's offset from Jan 1, 1904, not 1970 */

===========

Please bear in mind that this patch set depends on an OpenBIOS update.

Alexander Graf (5):
  PPC: mac99: Fix core99 timer frequency
  PPC: mac_nvram: Remove unused functions
  PPC: mac_nvram: Allow 2 and 4 byte accesses
  PPC: mac_nvram: Split NVRAM into OF and OSX parts
  PPC: mac99: Expose NVRAM linearly

 hw/misc/macio/macio.c |   9 ++++-
 hw/nvram/mac_nvram.c  | 109 +++++++++++++++++++++++++++++++++-----------------
 hw/ppc/mac.h          |   2 -
 hw/ppc/mac_newworld.c |   7 ++--
 include/hw/ppc/ppc.h  |   1 +
 5 files changed, 84 insertions(+), 44 deletions(-)

-- 
1.8.1.4

[Qemu-devel] [PATCH 1/5] PPC: mac99: Fix core99 timer frequency

[Alexander Graf]

There is a special timer in the mac99 machine that we recently started
to emulate. Unfortunately we emulated it in the wrong frequency.

This patch adapts the frequency Mac OS X uses to evaluate results from
this timer, making calculations it bases off of it work.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/misc/macio/macio.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 47f45f5..35eaa00 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -243,13 +243,18 @@ static void timer_write(void *opaque, hwaddr addr, uint64_t value,
 static uint64_t timer_read(void *opaque, hwaddr addr, unsigned size)
 {
     uint32_t value = 0;
+    uint64_t systime = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+    uint64_t kltime;
+
+    kltime = muldiv64(systime, 4194300, get_ticks_per_sec() * 4);
+    kltime = muldiv64(kltime, 18432000, 1048575);
 
     switch (addr) {
     case 0x38:
-        value = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+        value = kltime;
         break;
     case 0x3c:
-        value = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) >> 32;
+        value = kltime >> 32;
         break;
     }
 
-- 
1.8.1.4

[Qemu-devel] [PATCH 2/5] PPC: mac_nvram: Remove unused functions

[Alexander Graf]

The macio_nvram_read and macio_nvram_write functions are never called,
just remove them.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/nvram/mac_nvram.c | 23 -----------------------
 hw/ppc/mac.h         |  2 --
 2 files changed, 25 deletions(-)

diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index 170b10b..bcff074 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -39,29 +39,6 @@
 
 #define DEF_SYSTEM_SIZE 0xc10
 
-/* Direct access to NVRAM */
-uint8_t macio_nvram_read(MacIONVRAMState *s, uint32_t addr)
-{
-    uint32_t ret;
-
-    if (addr < s->size) {
-        ret = s->data[addr];
-    } else {
-        ret = -1;
-    }
-    NVR_DPRINTF("read addr %04" PRIx32 " val %" PRIx8 "\n", addr, ret);
-
-    return ret;
-}
-
-void macio_nvram_write(MacIONVRAMState *s, uint32_t addr, uint8_t val)
-{
-    NVR_DPRINTF("write addr %04" PRIx32 " val %" PRIx8 "\n", addr, val);
-    if (addr < s->size) {
-        s->data[addr] = val;
-    }
-}
-
 /* macio style NVRAM device */
 static void macio_nvram_writeb(void *opaque, hwaddr addr,
                                uint64_t value, unsigned size)
diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index c1faf9c..23536f4 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -178,6 +178,4 @@ typedef struct MacIONVRAMState {
 } MacIONVRAMState;
 
 void pmac_format_nvram_partition (MacIONVRAMState *nvr, int len);
-uint8_t macio_nvram_read(MacIONVRAMState *s, uint32_t addr);
-void macio_nvram_write(MacIONVRAMState *s, uint32_t addr, uint8_t val);
 #endif /* !defined(__PPC_MAC_H__) */
-- 
1.8.1.4

[Qemu-devel] [PATCH 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses

[Alexander Graf]

The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.

Add support for higher register size granularities.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/nvram/mac_nvram.c | 43 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index bcff074..0a6df44 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -40,32 +40,53 @@
 #define DEF_SYSTEM_SIZE 0xc10
 
 /* macio style NVRAM device */
-static void macio_nvram_writeb(void *opaque, hwaddr addr,
-                               uint64_t value, unsigned size)
+static void macio_nvram_write(void *opaque, hwaddr addr,
+                              uint64_t value, unsigned size)
 {
     MacIONVRAMState *s = opaque;
 
     addr = (addr >> s->it_shift) & (s->size - 1);
-    s->data[addr] = value;
-    NVR_DPRINTF("writeb addr %04" PHYS_PRIx " val %" PRIx64 "\n", addr, value);
+    switch (size) {
+    case 1:
+        s->data[addr] = value;
+        break;
+    case 2:
+        stw_be_p(&s->data[addr], value);
+        break;
+    case 4:
+        stl_be_p(&s->data[addr], value);
+        break;
+    }
+    NVR_DPRINTF("write%d addr %04" PRIx64 " val %" PRIx64 "\n", size, addr,
+                value);
 }
 
-static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
-                                  unsigned size)
+static uint64_t macio_nvram_read(void *opaque, hwaddr addr,
+                                 unsigned size)
 {
     MacIONVRAMState *s = opaque;
-    uint32_t value;
+    uint32_t value = 0;
 
     addr = (addr >> s->it_shift) & (s->size - 1);
-    value = s->data[addr];
-    NVR_DPRINTF("readb addr %04x val %x\n", (int)addr, value);
+    switch (size) {
+    case 1:
+        value = s->data[addr];
+        break;
+    case 2:
+        value = lduw_be_p(&s->data[addr]);
+        break;
+    case 4:
+        value = ldl_be_p(&s->data[addr]);
+        break;
+    }
+    NVR_DPRINTF("read%d addr %04x val %x\n", size, (int)addr, value);
 
     return value;
 }
 
 static const MemoryRegionOps macio_nvram_ops = {
-    .read = macio_nvram_readb,
-    .write = macio_nvram_writeb,
+    .read = macio_nvram_read,
+    .write = macio_nvram_write,
     .endianness = DEVICE_BIG_ENDIAN,
 };
 
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses

[Paolo Bonzini]

Il 13/07/2014 18:17, Alexander Graf ha scritto:
> The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
> just as well as 1byte accesses. In fact, Mac OS X uses those.
>
> Add support for higher register size granularities.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  hw/nvram/mac_nvram.c | 43 ++++++++++++++++++++++++++++++++-----------
>  1 file changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
> index bcff074..0a6df44 100644
> --- a/hw/nvram/mac_nvram.c
> +++ b/hw/nvram/mac_nvram.c
> @@ -40,32 +40,53 @@
>  #define DEF_SYSTEM_SIZE 0xc10
>
>  /* macio style NVRAM device */
> -static void macio_nvram_writeb(void *opaque, hwaddr addr,
> -                               uint64_t value, unsigned size)
> +static void macio_nvram_write(void *opaque, hwaddr addr,
> +                              uint64_t value, unsigned size)
>  {
>      MacIONVRAMState *s = opaque;
>
>      addr = (addr >> s->it_shift) & (s->size - 1);
> -    s->data[addr] = value;
> -    NVR_DPRINTF("writeb addr %04" PHYS_PRIx " val %" PRIx64 "\n", addr, value);
> +    switch (size) {
> +    case 1:
> +        s->data[addr] = value;
> +        break;
> +    case 2:
> +        stw_be_p(&s->data[addr], value);
> +        break;
> +    case 4:
> +        stl_be_p(&s->data[addr], value);
> +        break;
> +    }
> +    NVR_DPRINTF("write%d addr %04" PRIx64 " val %" PRIx64 "\n", size, addr,
> +                value);
>  }
>
> -static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
> -                                  unsigned size)
> +static uint64_t macio_nvram_read(void *opaque, hwaddr addr,
> +                                 unsigned size)
>  {
>      MacIONVRAMState *s = opaque;
> -    uint32_t value;
> +    uint32_t value = 0;
>
>      addr = (addr >> s->it_shift) & (s->size - 1);
> -    value = s->data[addr];
> -    NVR_DPRINTF("readb addr %04x val %x\n", (int)addr, value);
> +    switch (size) {
> +    case 1:
> +        value = s->data[addr];
> +        break;
> +    case 2:
> +        value = lduw_be_p(&s->data[addr]);
> +        break;
> +    case 4:
> +        value = ldl_be_p(&s->data[addr]);
> +        break;
> +    }
> +    NVR_DPRINTF("read%d addr %04x val %x\n", size, (int)addr, value);
>
>      return value;
>  }
>
>  static const MemoryRegionOps macio_nvram_ops = {
> -    .read = macio_nvram_readb,
> -    .write = macio_nvram_writeb,
> +    .read = macio_nvram_read,
> +    .write = macio_nvram_write,
>      .endianness = DEVICE_BIG_ENDIAN,
>  };
>
>

I think this ought to be enough:

  static const MemoryRegionOps test_ioport_byte_ops = {
      .read = macio_nvram_readb,
      .write = macio_nvram_writeb,
+    .valid.min_access_size = 1,
+    .valid.max_access_size = 4,
+    .impl.min_access_size = 1,
+    .impl.max_access_size = 1,
      .endianness = DEVICE_BIG_ENDIAN,
  };


Paolo

Re: [Qemu-devel] [PATCH 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses

[Alexander Graf]

On 14.07.14 08:41, Paolo Bonzini wrote:
> Il 13/07/2014 18:17, Alexander Graf ha scritto:
>> The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
>> just as well as 1byte accesses. In fact, Mac OS X uses those.
>>
>> Add support for higher register size granularities.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>>  hw/nvram/mac_nvram.c | 43 ++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 32 insertions(+), 11 deletions(-)
>>
>> diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
>> index bcff074..0a6df44 100644
>> --- a/hw/nvram/mac_nvram.c
>> +++ b/hw/nvram/mac_nvram.c
>> @@ -40,32 +40,53 @@
>>  #define DEF_SYSTEM_SIZE 0xc10
>>
>>  /* macio style NVRAM device */
>> -static void macio_nvram_writeb(void *opaque, hwaddr addr,
>> -                               uint64_t value, unsigned size)
>> +static void macio_nvram_write(void *opaque, hwaddr addr,
>> +                              uint64_t value, unsigned size)
>>  {
>>      MacIONVRAMState *s = opaque;
>>
>>      addr = (addr >> s->it_shift) & (s->size - 1);
>> -    s->data[addr] = value;
>> -    NVR_DPRINTF("writeb addr %04" PHYS_PRIx " val %" PRIx64 "\n", 
>> addr, value);
>> +    switch (size) {
>> +    case 1:
>> +        s->data[addr] = value;
>> +        break;
>> +    case 2:
>> +        stw_be_p(&s->data[addr], value);
>> +        break;
>> +    case 4:
>> +        stl_be_p(&s->data[addr], value);
>> +        break;
>> +    }
>> +    NVR_DPRINTF("write%d addr %04" PRIx64 " val %" PRIx64 "\n", 
>> size, addr,
>> +                value);
>>  }
>>
>> -static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
>> -                                  unsigned size)
>> +static uint64_t macio_nvram_read(void *opaque, hwaddr addr,
>> +                                 unsigned size)
>>  {
>>      MacIONVRAMState *s = opaque;
>> -    uint32_t value;
>> +    uint32_t value = 0;
>>
>>      addr = (addr >> s->it_shift) & (s->size - 1);
>> -    value = s->data[addr];
>> -    NVR_DPRINTF("readb addr %04x val %x\n", (int)addr, value);
>> +    switch (size) {
>> +    case 1:
>> +        value = s->data[addr];
>> +        break;
>> +    case 2:
>> +        value = lduw_be_p(&s->data[addr]);
>> +        break;
>> +    case 4:
>> +        value = ldl_be_p(&s->data[addr]);
>> +        break;
>> +    }
>> +    NVR_DPRINTF("read%d addr %04x val %x\n", size, (int)addr, value);
>>
>>      return value;
>>  }
>>
>>  static const MemoryRegionOps macio_nvram_ops = {
>> -    .read = macio_nvram_readb,
>> -    .write = macio_nvram_writeb,
>> +    .read = macio_nvram_read,
>> +    .write = macio_nvram_write,
>>      .endianness = DEVICE_BIG_ENDIAN,
>>  };
>>
>>
>
> I think this ought to be enough:
>
>  static const MemoryRegionOps test_ioport_byte_ops = {
>      .read = macio_nvram_readb,
>      .write = macio_nvram_writeb,
> +    .valid.min_access_size = 1,
> +    .valid.max_access_size = 4,
> +    .impl.min_access_size = 1,
> +    .impl.max_access_size = 1,
>      .endianness = DEVICE_BIG_ENDIAN,
>  };

Heh - I knew there had to be a trick to this :). That's certainly a lot 
cleaner.


Alex

[Qemu-devel] [PATCH v2 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses

[Alexander Graf]

The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.

Add support for higher register size granularities.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Leave single-byte accesses, but mark the MMIO handler 4-byte capable
    with 1-byte granularity (thanks to Paolo for the suggestion!)
---
 hw/nvram/mac_nvram.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index bcff074..7656951 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -66,6 +66,10 @@ static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
 static const MemoryRegionOps macio_nvram_ops = {
     .read = macio_nvram_readb,
     .write = macio_nvram_writeb,
+    .valid.min_access_size = 1,
+    .valid.max_access_size = 4,
+    .impl.min_access_size = 1,
+    .impl.max_access_size = 1,
     .endianness = DEVICE_BIG_ENDIAN,
 };
 
-- 
1.8.1.4

[Qemu-devel] [PATCH 4/5] PPC: mac_nvram: Split NVRAM into OF and OSX parts

[Alexander Graf]

Mac OS X (at least with -M mac99) searches for a valid NVRAM partition
of a special Apple type. If it can't find that partition in the first
half of NVRAM, it will look at the second half.

There are a few implications from this. The first is that we need to
split NVRAM into 2 halves - one for Open Firmware use, the other one for
Mac OS X. Without this split Mac OS X will just loop endlessly over the
second half trying to find a partition.

The other implication is that we should provide a specially crafted Mac
OS X compatible NVRAM partition on the second half that Mac OS X can
happily use as it sees fit.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/nvram/mac_nvram.c | 43 ++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index 0a6df44..52eb9bd 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -26,6 +26,7 @@
 #include "hw/nvram/openbios_firmware_abi.h"
 #include "sysemu/sysemu.h"
 #include "hw/ppc/mac.h"
+#include <zlib.h>
 
 /* debug NVR */
 //#define DEBUG_NVR
@@ -154,15 +155,16 @@ static void macio_nvram_register_types(void)
 }
 
 /* Set up a system OpenBIOS NVRAM partition */
-void pmac_format_nvram_partition (MacIONVRAMState *nvr, int len)
+static void pmac_format_nvram_partition_of(MacIONVRAMState *nvr, int off,
+                                           int len)
 {
     unsigned int i;
-    uint32_t start = 0, end;
+    uint32_t start = off, end;
     struct OpenBIOS_nvpart_v1 *part_header;
 
     // OpenBIOS nvram variables
     // Variable partition
-    part_header = (struct OpenBIOS_nvpart_v1 *)nvr->data;
+    part_header = (struct OpenBIOS_nvpart_v1 *)&nvr->data[start];
     part_header->signature = OPENBIOS_PART_SYSTEM;
     pstrcpy(part_header->name, sizeof(part_header->name), "system");
 
@@ -190,4 +192,39 @@ void pmac_format_nvram_partition (MacIONVRAMState *nvr, int len)
     OpenBIOS_finish_partition(part_header, end - start);
 }
 
+#define OSX_NVRAM_SIGNATURE     (0x5A)
+
+/* Set up a Mac OS X NVRAM partition */
+static void pmac_format_nvram_partition_osx(MacIONVRAMState *nvr, int off,
+                                            int len)
+{
+    uint32_t start = off;
+    struct OpenBIOS_nvpart_v1 *part_header;
+    unsigned char *data = &nvr->data[start];
+
+    /* empty partition */
+    part_header = (struct OpenBIOS_nvpart_v1 *)data;
+    part_header->signature = OSX_NVRAM_SIGNATURE;
+    pstrcpy(part_header->name, sizeof(part_header->name), "wwwwwwwwwwww");
+
+    OpenBIOS_finish_partition(part_header, len);
+
+    /* Generation */
+    stl_be_p(&data[20], 2);
+
+    /* Adler32 checksum */
+    stl_be_p(&data[16], adler32(0, &data[20], len - 20));
+}
+
+/* Set up NVRAM with OF and OSX partitions */
+void pmac_format_nvram_partition(MacIONVRAMState *nvr, int len)
+{
+    /*
+     * Mac OS X expects side "B" of the flash at the second half of NVRAM,
+     * so we use half of the chip for OF and the other half for a free OSX
+     * partition.
+     */
+    pmac_format_nvram_partition_of(nvr, 0, len / 2);
+    pmac_format_nvram_partition_osx(nvr, len / 2, len / 2);
+}
 type_init(macio_nvram_register_types)
-- 
1.8.1.4

[Qemu-devel] [PATCH 5/5] PPC: mac99: Expose NVRAM linearly

[Alexander Graf]

The mac99 machine really doesn't have any shifts in NVRAM usage. It simply has
a 1:1 MMIO mapped space where a guest can access the NVRAM data.

This patch fixes up the incorrect format we use for NVRAM today, making Mac OS
X happy and able to read NVRAM.

This patch also requires a new OpenBIOS version. To ensure bisectaibility,
we provide a fw_cfg hint to tell OpenBIOS that NVRAM is now flat.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

WARNING! This patch breaks compatibility with older OpenBIOS which can
no longer read data from NVRAM after this patch is applied to populate
its prom variables.
---
 hw/ppc/mac_newworld.c | 7 ++++---
 include/hw/ppc/ppc.h  | 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index e96b635..32ee2f2 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -435,12 +435,12 @@ static void ppc_core99_init(MachineState *machine)
     }
 #endif
     dev = qdev_create(NULL, TYPE_MACIO_NVRAM);
-    qdev_prop_set_uint32(dev, "size", 0x2000);
-    qdev_prop_set_uint32(dev, "it_shift", 1);
+    qdev_prop_set_uint32(dev, "size", 0x4000);
+    qdev_prop_set_uint32(dev, "it_shift", 0);
     qdev_init_nofail(dev);
     sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, nvram_addr);
     nvr = MACIO_NVRAM(dev);
-    pmac_format_nvram_partition(nvr, 0x2000);
+    pmac_format_nvram_partition(nvr, 0x4000);
     /* No PCI init: the BIOS will do it */
 
     fw_cfg = fw_cfg_init(0, 0, CFG_ADDR, CFG_ADDR + 2);
@@ -482,6 +482,7 @@ static void ppc_core99_init(MachineState *machine)
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
     fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
+    fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_FLAT, 1);
 
     qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
 }
diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 14efd0c..7b13cee 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -94,6 +94,7 @@ enum {
 #define FW_CFG_PPC_KVM_PID      (FW_CFG_ARCH_LOCAL + 0x07)
 #define FW_CFG_PPC_NVRAM_ADDR   (FW_CFG_ARCH_LOCAL + 0x08)
 #define FW_CFG_PPC_BUSFREQ      (FW_CFG_ARCH_LOCAL + 0x09)
+#define FW_CFG_PPC_NVRAM_FLAT   (FW_CFG_ARCH_LOCAL + 0x0a)
 
 #define PPC_SERIAL_MM_BAUDBASE 399193
 
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Programmingkid]

On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote:

> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
> over a few issues that prevented it from doing so.
> 
> With these patches applied I still can't properly boot Mac OS X with -M mac99,
> but I get a lot further than before. The biggest issue that's left now is to
> properly fake Mac OS X into believing our timebase frequency. If I hack up the
> cuda timer I can successfully boot Mac OS X on mac99:
> 

Which version of Mac OS X are you testing out with this patch?

Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Alexander Graf]

> Am 13.07.2014 um 19:51 schrieb Programmingkid <programmingkidx@gmail.com>:
> 
> 
>> On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote:
>> 
>> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
>> over a few issues that prevented it from doing so.
>> 
>> With these patches applied I still can't properly boot Mac OS X with -M mac99,
>> but I get a lot further than before. The biggest issue that's left now is to
>> properly fake Mac OS X into believing our timebase frequency. If I hack up the
>> cuda timer I can successfully boot Mac OS X on mac99:
> 
> Which version of Mac OS X are you testing out with this patch?

10.2.something and 10.4.11.

Alex

Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Mark Cave-Ayland]

On 13/07/14 17:17, Alexander Graf wrote:

> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
> over a few issues that prevented it from doing so.
>
> With these patches applied I still can't properly boot Mac OS X with -M mac99,
> but I get a lot further than before. The biggest issue that's left now is to
> properly fake Mac OS X into believing our timebase frequency. If I hack up the
> cuda timer I can successfully boot Mac OS X on mac99:

No complaints from me on this series (I see Paolo has already commented 
suggested some MemoryRegion changes). Is this part of a bug-fix series 
to fix a -M mac99 regression on KVM or is it 2.2 material?


ATB,

Mark.

Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Alexander Graf]

On 14.07.14 15:58, Mark Cave-Ayland wrote:
> On 13/07/14 17:17, Alexander Graf wrote:
>
>> While trying to get Mac OS X booting with our -M mac99 emulation I 
>> stumbled
>> over a few issues that prevented it from doing so.
>>
>> With these patches applied I still can't properly boot Mac OS X with 
>> -M mac99,
>> but I get a lot further than before. The biggest issue that's left 
>> now is to
>> properly fake Mac OS X into believing our timebase frequency. If I 
>> hack up the
>> cuda timer I can successfully boot Mac OS X on mac99:
>
> No complaints from me on this series (I see Paolo has already 
> commented suggested some MemoryRegion changes). Is this part of a 
> bug-fix series to fix a -M mac99 regression on KVM or is it 2.2 material?

Mac99 never really worked for me, so I think this can easily be 2.2 
material. Maybe we can get the PCI bus working during the 2.2 
development time frame too then.

I mostly CC'ed you for the NVRAM patch, as that depends on an OpenBIOS 
change :).


Alex

Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes

[Mark Cave-Ayland]

On 14/07/14 15:00, Alexander Graf wrote:

> On 14.07.14 15:58, Mark Cave-Ayland wrote:
>> On 13/07/14 17:17, Alexander Graf wrote:
>>
>>> While trying to get Mac OS X booting with our -M mac99 emulation I
>>> stumbled
>>> over a few issues that prevented it from doing so.
>>>
>>> With these patches applied I still can't properly boot Mac OS X with
>>> -M mac99,
>>> but I get a lot further than before. The biggest issue that's left
>>> now is to
>>> properly fake Mac OS X into believing our timebase frequency. If I
>>> hack up the
>>> cuda timer I can successfully boot Mac OS X on mac99:
>>
>> No complaints from me on this series (I see Paolo has already
>> commented suggested some MemoryRegion changes). Is this part of a
>> bug-fix series to fix a -M mac99 regression on KVM or is it 2.2 material?
>
> Mac99 never really worked for me, so I think this can easily be 2.2
> material. Maybe we can get the PCI bus working during the 2.2
> development time frame too then.
>
> I mostly CC'ed you for the NVRAM patch, as that depends on an OpenBIOS
> change :).

Yup, saw that commit go into SVN trunk. Okay so no need to worry about 
re-running my OpenBIOS boot tests before the 2.1 release then :)


ATB,

Mark.