| Message ID | 20140602231148.104752F472@mono.eik.bme.hu |
|---|---|
| State | New |
| Headers | show |
Ping! <http://patchwork.ozlabs.org/patch/355103/> On Sat, 12 Apr 2014, BALATON Zoltan wrote: > Bring the memory map closer to a PowerMac3,1 model by removing unused > areas and adding the VGA and network cards after the macio to let the > latter be mapped from 0x80000000 like on real hardware. (On real > hardware the graphics and network cards are on separate buses but we > don't model that yet.) > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > --- > > This patch is intended to bring memory layout closer to what's seen in > these dumps: > > http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt > http://raveland.org/ports/eeprom.txt > http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 > > v2: Added back unin2_memory region that Darwin seems to like better > > --- > hw/pci-host/uninorth.c | 2 +- > hw/ppc/mac_newworld.c | 14 +++++++------- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c > index e72fe2a..21f805f 100644 > --- a/hw/pci-host/uninorth.c > +++ b/hw/pci-host/uninorth.c > @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, > d = UNI_NORTH_PCI_HOST_BRIDGE(dev); > memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", 0x100000000ULL); > memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", &d->pci_mmio, > - 0x80000000ULL, 0x70000000ULL); > + 0x80000000ULL, 0x10000000ULL); > memory_region_add_subregion(address_space_mem, 0x80000000ULL, > &d->pci_hole); > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > index 4bdaa8d..a4e5044 100644 > --- a/hw/ppc/mac_newworld.c > +++ b/hw/ppc/mac_newworld.c > @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) > machine_arch = ARCH_MAC99; > } > /* init basic PC hardware */ > - pci_vga_init(pci_bus); > - > escc_mem = escc_init(0, pic[0x25], pic[0x24], > serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); > memory_region_init_alias(escc_bar, NULL, "escc-bar", > escc_mem, 0, memory_region_size(escc_mem)); > > - for(i = 0; i < nb_nics; i++) > - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); > - > - ide_drive_get(hd, MAX_IDE_BUS); > - > macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); > dev = DEVICE(macio); > qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ > @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) > macio_init(macio, pic_mem, escc_bar); > > /* We only emulate 2 out of 3 IDE controllers for now */ > + ide_drive_get(hd, MAX_IDE_BUS); > + > macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), > "ide[0]")); > macio_ide_init_drives(macio_ide, hd); > @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) > } > } > > + pci_vga_init(pci_bus); > + > if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != 8) > graphic_depth = 15; > > + for(i = 0; i < nb_nics; i++) > + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); > + > /* The NewWorld NVRAM is not located in the MacIO device */ > dev = qdev_create(NULL, TYPE_MACIO_NVRAM); > qdev_prop_set_uint32(dev, "size", 0x2000); > -- > 1.8.1.5 > > >
Ping again. This patch already missed two pull requests without getting any comments. I hope you can look at it now. Regards, BALATON Zoltan On Mon, 9 Jun 2014, BALATON Zoltan wrote: > > Ping! <http://patchwork.ozlabs.org/patch/355103/> > > On Sat, 12 Apr 2014, BALATON Zoltan wrote: >> Bring the memory map closer to a PowerMac3,1 model by removing unused >> areas and adding the VGA and network cards after the macio to let the >> latter be mapped from 0x80000000 like on real hardware. (On real >> hardware the graphics and network cards are on separate buses but we >> don't model that yet.) >> >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >> --- >> >> This patch is intended to bring memory layout closer to what's seen in >> these dumps: >> >> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >> http://raveland.org/ports/eeprom.txt >> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >> >> v2: Added back unin2_memory region that Darwin seems to like better >> >> --- >> hw/pci-host/uninorth.c | 2 +- >> hw/ppc/mac_newworld.c | 14 +++++++------- >> 2 files changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >> index e72fe2a..21f805f 100644 >> --- a/hw/pci-host/uninorth.c >> +++ b/hw/pci-host/uninorth.c >> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >> 0x100000000ULL); >> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >> &d->pci_mmio, >> - 0x80000000ULL, 0x70000000ULL); >> + 0x80000000ULL, 0x10000000ULL); >> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >> &d->pci_hole); >> >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >> index 4bdaa8d..a4e5044 100644 >> --- a/hw/ppc/mac_newworld.c >> +++ b/hw/ppc/mac_newworld.c >> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) >> machine_arch = ARCH_MAC99; >> } >> /* init basic PC hardware */ >> - pci_vga_init(pci_bus); >> - >> escc_mem = escc_init(0, pic[0x25], pic[0x24], >> serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); >> memory_region_init_alias(escc_bar, NULL, "escc-bar", >> escc_mem, 0, memory_region_size(escc_mem)); >> >> - for(i = 0; i < nb_nics; i++) >> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >> - >> - ide_drive_get(hd, MAX_IDE_BUS); >> - >> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >> dev = DEVICE(macio); >> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >> macio_init(macio, pic_mem, escc_bar); >> >> /* We only emulate 2 out of 3 IDE controllers for now */ >> + ide_drive_get(hd, MAX_IDE_BUS); >> + >> macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), >> "ide[0]")); >> macio_ide_init_drives(macio_ide, hd); >> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >> } >> } >> >> + pci_vga_init(pci_bus); >> + >> if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != 8) >> graphic_depth = 15; >> >> + for(i = 0; i < nb_nics; i++) >> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >> + >> /* The NewWorld NVRAM is not located in the MacIO device */ >> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >> qdev_prop_set_uint32(dev, "size", 0x2000); >> -- >> 1.8.1.5 >> >> >> > >
On 12.04.14 11:20, BALATON Zoltan wrote: > Bring the memory map closer to a PowerMac3,1 model by removing unused > areas and adding the VGA and network cards after the macio to let the > latter be mapped from 0x80000000 like on real hardware. (On real > hardware the graphics and network cards are on separate buses but we > don't model that yet.) > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > --- > > This patch is intended to bring memory layout closer to what's seen in > these dumps: > > http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt > http://raveland.org/ports/eeprom.txt > http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 > > v2: Added back unin2_memory region that Darwin seems to like better > > --- > hw/pci-host/uninorth.c | 2 +- > hw/ppc/mac_newworld.c | 14 +++++++------- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c > index e72fe2a..21f805f 100644 > --- a/hw/pci-host/uninorth.c > +++ b/hw/pci-host/uninorth.c > @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, > d = UNI_NORTH_PCI_HOST_BRIDGE(dev); > memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", 0x100000000ULL); > memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", &d->pci_mmio, > - 0x80000000ULL, 0x70000000ULL); > + 0x80000000ULL, 0x10000000ULL); Doesn't OpenBIOS need to know about this change so it can update its device tree? > memory_region_add_subregion(address_space_mem, 0x80000000ULL, > &d->pci_hole); > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > index 4bdaa8d..a4e5044 100644 > --- a/hw/ppc/mac_newworld.c > +++ b/hw/ppc/mac_newworld.c > @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) > machine_arch = ARCH_MAC99; > } > /* init basic PC hardware */ > - pci_vga_init(pci_bus); > - > escc_mem = escc_init(0, pic[0x25], pic[0x24], > serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); > memory_region_init_alias(escc_bar, NULL, "escc-bar", > escc_mem, 0, memory_region_size(escc_mem)); > > - for(i = 0; i < nb_nics; i++) > - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); > - > - ide_drive_get(hd, MAX_IDE_BUS); > - > macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); > dev = DEVICE(macio); > qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ > @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) > macio_init(macio, pic_mem, escc_bar); > > /* We only emulate 2 out of 3 IDE controllers for now */ > + ide_drive_get(hd, MAX_IDE_BUS); > + > macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), > "ide[0]")); > macio_ide_init_drives(macio_ide, hd); > @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) > } > } > > + pci_vga_init(pci_bus); > + > if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != 8) > graphic_depth = 15; > > + for(i = 0; i < nb_nics; i++) > + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); > + > /* The NewWorld NVRAM is not located in the MacIO device */ > dev = qdev_create(NULL, TYPE_MACIO_NVRAM); > qdev_prop_set_uint32(dev, "size", 0x2000); I presume all the changes above only change the devfn ordering? Alex
On Tue, 17 Jun 2014, Alexander Graf wrote: > On 12.04.14 11:20, BALATON Zoltan wrote: >> Bring the memory map closer to a PowerMac3,1 model by removing unused >> areas and adding the VGA and network cards after the macio to let the >> latter be mapped from 0x80000000 like on real hardware. (On real >> hardware the graphics and network cards are on separate buses but we >> don't model that yet.) >> >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >> --- >> >> This patch is intended to bring memory layout closer to what's seen in >> these dumps: >> >> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >> http://raveland.org/ports/eeprom.txt >> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >> >> v2: Added back unin2_memory region that Darwin seems to like better >> >> --- >> hw/pci-host/uninorth.c | 2 +- >> hw/ppc/mac_newworld.c | 14 +++++++------- >> 2 files changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >> index e72fe2a..21f805f 100644 >> --- a/hw/pci-host/uninorth.c >> +++ b/hw/pci-host/uninorth.c >> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >> 0x100000000ULL); >> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >> &d->pci_mmio, >> - 0x80000000ULL, 0x70000000ULL); >> + 0x80000000ULL, 0x10000000ULL); > > Doesn't OpenBIOS need to know about this change so it can update its device > tree? No. >> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >> &d->pci_hole); >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >> index 4bdaa8d..a4e5044 100644 >> --- a/hw/ppc/mac_newworld.c >> +++ b/hw/ppc/mac_newworld.c >> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) >> machine_arch = ARCH_MAC99; >> } >> /* init basic PC hardware */ >> - pci_vga_init(pci_bus); >> - >> escc_mem = escc_init(0, pic[0x25], pic[0x24], >> serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); >> memory_region_init_alias(escc_bar, NULL, "escc-bar", >> escc_mem, 0, memory_region_size(escc_mem)); >> - for(i = 0; i < nb_nics; i++) >> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >> - >> - ide_drive_get(hd, MAX_IDE_BUS); >> - >> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >> dev = DEVICE(macio); >> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >> macio_init(macio, pic_mem, escc_bar); >> /* We only emulate 2 out of 3 IDE controllers for now */ >> + ide_drive_get(hd, MAX_IDE_BUS); >> + >> macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), >> "ide[0]")); >> macio_ide_init_drives(macio_ide, hd); >> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >> } >> } >> + pci_vga_init(pci_bus); >> + >> if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != 8) >> graphic_depth = 15; >> + for(i = 0; i < nb_nics; i++) >> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >> + >> /* The NewWorld NVRAM is not located in the MacIO device */ >> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >> qdev_prop_set_uint32(dev, "size", 0x2000); > > I presume all the changes above only change the devfn ordering? It changes the addresses assigned to devices which is needed for MorphOS to work as it hardcodes the mmio locations of some (actually most) devices. Regards, BALATON Zoltan
On 17.06.14 11:36, BALATON Zoltan wrote: > On Tue, 17 Jun 2014, Alexander Graf wrote: >> On 12.04.14 11:20, BALATON Zoltan wrote: >>> Bring the memory map closer to a PowerMac3,1 model by removing unused >>> areas and adding the VGA and network cards after the macio to let the >>> latter be mapped from 0x80000000 like on real hardware. (On real >>> hardware the graphics and network cards are on separate buses but we >>> don't model that yet.) >>> >>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>> --- >>> >>> This patch is intended to bring memory layout closer to what's seen in >>> these dumps: >>> >>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >>> http://raveland.org/ports/eeprom.txt >>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >>> >>> v2: Added back unin2_memory region that Darwin seems to like better >>> >>> --- >>> hw/pci-host/uninorth.c | 2 +- >>> hw/ppc/mac_newworld.c | 14 +++++++------- >>> 2 files changed, 8 insertions(+), 8 deletions(-) >>> >>> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >>> index e72fe2a..21f805f 100644 >>> --- a/hw/pci-host/uninorth.c >>> +++ b/hw/pci-host/uninorth.c >>> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >>> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >>> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >>> 0x100000000ULL); >>> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >>> &d->pci_mmio, >>> - 0x80000000ULL, 0x70000000ULL); >>> + 0x80000000ULL, 0x10000000ULL); >> >> Doesn't OpenBIOS need to know about this change so it can update its >> device tree? > > No. We don't expose the pci-hole size in device tree? > >>> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >>> &d->pci_hole); >>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >>> index 4bdaa8d..a4e5044 100644 >>> --- a/hw/ppc/mac_newworld.c >>> +++ b/hw/ppc/mac_newworld.c >>> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState >>> *machine) >>> machine_arch = ARCH_MAC99; >>> } >>> /* init basic PC hardware */ >>> - pci_vga_init(pci_bus); >>> - >>> escc_mem = escc_init(0, pic[0x25], pic[0x24], >>> serial_hds[0], serial_hds[1], ESCC_CLOCK, >>> 4); >>> memory_region_init_alias(escc_bar, NULL, "escc-bar", >>> escc_mem, 0, >>> memory_region_size(escc_mem)); >>> - for(i = 0; i < nb_nics; i++) >>> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>> - >>> - ide_drive_get(hd, MAX_IDE_BUS); >>> - >>> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >>> dev = DEVICE(macio); >>> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >>> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >>> macio_init(macio, pic_mem, escc_bar); >>> /* We only emulate 2 out of 3 IDE controllers for now */ >>> + ide_drive_get(hd, MAX_IDE_BUS); >>> + >>> macio_ide = >>> MACIO_IDE(object_resolve_path_component(OBJECT(macio), >>> "ide[0]")); >>> macio_ide_init_drives(macio_ide, hd); >>> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >>> } >>> } >>> + pci_vga_init(pci_bus); >>> + >>> if (graphic_depth != 15 && graphic_depth != 32 && >>> graphic_depth != 8) >>> graphic_depth = 15; >>> + for(i = 0; i < nb_nics; i++) >>> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>> + >>> /* The NewWorld NVRAM is not located in the MacIO device */ >>> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >>> qdev_prop_set_uint32(dev, "size", 0x2000); >> >> I presume all the changes above only change the devfn ordering? > > It changes the addresses assigned to devices which is needed for > MorphOS to work as it hardcodes the mmio locations of some (actually > most) devices. I don't see how the ordering change here could possibly change MMIO locations for anything? Alex
On Tue, 17 Jun 2014, Alexander Graf wrote: > On 17.06.14 11:36, BALATON Zoltan wrote: >> On Tue, 17 Jun 2014, Alexander Graf wrote: >>> On 12.04.14 11:20, BALATON Zoltan wrote: >>>> Bring the memory map closer to a PowerMac3,1 model by removing unused >>>> areas and adding the VGA and network cards after the macio to let the >>>> latter be mapped from 0x80000000 like on real hardware. (On real >>>> hardware the graphics and network cards are on separate buses but we >>>> don't model that yet.) >>>> >>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>> --- >>>> >>>> This patch is intended to bring memory layout closer to what's seen in >>>> these dumps: >>>> >>>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >>>> http://raveland.org/ports/eeprom.txt >>>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >>>> >>>> v2: Added back unin2_memory region that Darwin seems to like better >>>> >>>> --- >>>> hw/pci-host/uninorth.c | 2 +- >>>> hw/ppc/mac_newworld.c | 14 +++++++------- >>>> 2 files changed, 8 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >>>> index e72fe2a..21f805f 100644 >>>> --- a/hw/pci-host/uninorth.c >>>> +++ b/hw/pci-host/uninorth.c >>>> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >>>> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >>>> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >>>> 0x100000000ULL); >>>> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >>>> &d->pci_mmio, >>>> - 0x80000000ULL, 0x70000000ULL); >>>> + 0x80000000ULL, 0x10000000ULL); >>> >>> Doesn't OpenBIOS need to know about this change so it can update its >>> device tree? >> >> No. > > We don't expose the pci-hole size in device tree? We do but already as 0x10000000. See: http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arch/ppc/qemu/init.c >>>> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >>>> &d->pci_hole); >>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >>>> index 4bdaa8d..a4e5044 100644 >>>> --- a/hw/ppc/mac_newworld.c >>>> +++ b/hw/ppc/mac_newworld.c >>>> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) >>>> machine_arch = ARCH_MAC99; >>>> } >>>> /* init basic PC hardware */ >>>> - pci_vga_init(pci_bus); >>>> - >>>> escc_mem = escc_init(0, pic[0x25], pic[0x24], >>>> serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); >>>> memory_region_init_alias(escc_bar, NULL, "escc-bar", >>>> escc_mem, 0, >>>> memory_region_size(escc_mem)); >>>> - for(i = 0; i < nb_nics; i++) >>>> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>> - >>>> - ide_drive_get(hd, MAX_IDE_BUS); >>>> - >>>> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >>>> dev = DEVICE(macio); >>>> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >>>> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >>>> macio_init(macio, pic_mem, escc_bar); >>>> /* We only emulate 2 out of 3 IDE controllers for now */ >>>> + ide_drive_get(hd, MAX_IDE_BUS); >>>> + >>>> macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), >>>> "ide[0]")); >>>> macio_ide_init_drives(macio_ide, hd); >>>> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >>>> } >>>> } >>>> + pci_vga_init(pci_bus); >>>> + >>>> if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != >>>> 8) >>>> graphic_depth = 15; >>>> + for(i = 0; i < nb_nics; i++) >>>> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>> + >>>> /* The NewWorld NVRAM is not located in the MacIO device */ >>>> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >>>> qdev_prop_set_uint32(dev, "size", 0x2000); >>> >>> I presume all the changes above only change the devfn ordering? >> >> It changes the addresses assigned to devices which is needed for MorphOS to >> work as it hardcodes the mmio locations of some (actually most) devices. > > I don't see how the ordering change here could possibly change MMIO locations > for anything? It's how OpenBIOS assigns MMIO addresses to pci devices. It does it by going through them in order and map them starting from the base address (with some allingment). I guess you could look at drivers/pci.c I think it's in there somewhere. Regards, BALATON Zoltan
Ping! On Tue, 17 Jun 2014, BALATON Zoltan wrote: > On Tue, 17 Jun 2014, Alexander Graf wrote: >> On 17.06.14 11:36, BALATON Zoltan wrote: >>> On Tue, 17 Jun 2014, Alexander Graf wrote: >>>> On 12.04.14 11:20, BALATON Zoltan wrote: >>>>> Bring the memory map closer to a PowerMac3,1 model by removing unused >>>>> areas and adding the VGA and network cards after the macio to let the >>>>> latter be mapped from 0x80000000 like on real hardware. (On real >>>>> hardware the graphics and network cards are on separate buses but we >>>>> don't model that yet.) >>>>> >>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>>> --- >>>>> >>>>> This patch is intended to bring memory layout closer to what's seen in >>>>> these dumps: >>>>> >>>>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >>>>> http://raveland.org/ports/eeprom.txt >>>>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >>>>> >>>>> v2: Added back unin2_memory region that Darwin seems to like better >>>>> >>>>> --- >>>>> hw/pci-host/uninorth.c | 2 +- >>>>> hw/ppc/mac_newworld.c | 14 +++++++------- >>>>> 2 files changed, 8 insertions(+), 8 deletions(-) >>>>> >>>>> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >>>>> index e72fe2a..21f805f 100644 >>>>> --- a/hw/pci-host/uninorth.c >>>>> +++ b/hw/pci-host/uninorth.c >>>>> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >>>>> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >>>>> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >>>>> 0x100000000ULL); >>>>> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >>>>> &d->pci_mmio, >>>>> - 0x80000000ULL, 0x70000000ULL); >>>>> + 0x80000000ULL, 0x10000000ULL); >>>> >>>> Doesn't OpenBIOS need to know about this change so it can update its >>>> device tree? >>> >>> No. >> >> We don't expose the pci-hole size in device tree? > > We do but already as 0x10000000. See: > http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arch/ppc/qemu/init.c > >>>>> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >>>>> &d->pci_hole); >>>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >>>>> index 4bdaa8d..a4e5044 100644 >>>>> --- a/hw/ppc/mac_newworld.c >>>>> +++ b/hw/ppc/mac_newworld.c >>>>> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) >>>>> machine_arch = ARCH_MAC99; >>>>> } >>>>> /* init basic PC hardware */ >>>>> - pci_vga_init(pci_bus); >>>>> - >>>>> escc_mem = escc_init(0, pic[0x25], pic[0x24], >>>>> serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); >>>>> memory_region_init_alias(escc_bar, NULL, "escc-bar", >>>>> escc_mem, 0, >>>>> memory_region_size(escc_mem)); >>>>> - for(i = 0; i < nb_nics; i++) >>>>> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>>> - >>>>> - ide_drive_get(hd, MAX_IDE_BUS); >>>>> - >>>>> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >>>>> dev = DEVICE(macio); >>>>> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >>>>> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >>>>> macio_init(macio, pic_mem, escc_bar); >>>>> /* We only emulate 2 out of 3 IDE controllers for now */ >>>>> + ide_drive_get(hd, MAX_IDE_BUS); >>>>> + >>>>> macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), >>>>> "ide[0]")); >>>>> macio_ide_init_drives(macio_ide, hd); >>>>> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >>>>> } >>>>> } >>>>> + pci_vga_init(pci_bus); >>>>> + >>>>> if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != >>>>> 8) >>>>> graphic_depth = 15; >>>>> + for(i = 0; i < nb_nics; i++) >>>>> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>>> + >>>>> /* The NewWorld NVRAM is not located in the MacIO device */ >>>>> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >>>>> qdev_prop_set_uint32(dev, "size", 0x2000); >>>> >>>> I presume all the changes above only change the devfn ordering? >>> >>> It changes the addresses assigned to devices which is needed for MorphOS >>> to work as it hardcodes the mmio locations of some (actually most) >>> devices. >> >> I don't see how the ordering change here could possibly change MMIO >> locations for anything? > > It's how OpenBIOS assigns MMIO addresses to pci devices. It does it by going > through them in order and map them starting from the base address (with some > allingment). I guess you could look at drivers/pci.c I think it's in there > somewhere. > > Regards, > BALATON Zoltan > >
On 17.06.14 12:24, BALATON Zoltan wrote: > On Tue, 17 Jun 2014, Alexander Graf wrote: >> On 17.06.14 11:36, BALATON Zoltan wrote: >>> On Tue, 17 Jun 2014, Alexander Graf wrote: >>>> On 12.04.14 11:20, BALATON Zoltan wrote: >>>>> Bring the memory map closer to a PowerMac3,1 model by removing unused >>>>> areas and adding the VGA and network cards after the macio to let the >>>>> latter be mapped from 0x80000000 like on real hardware. (On real >>>>> hardware the graphics and network cards are on separate buses but we >>>>> don't model that yet.) >>>>> >>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>>> --- >>>>> >>>>> This patch is intended to bring memory layout closer to what's >>>>> seen in >>>>> these dumps: >>>>> >>>>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >>>>> http://raveland.org/ports/eeprom.txt >>>>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >>>>> >>>>> v2: Added back unin2_memory region that Darwin seems to like better >>>>> >>>>> --- >>>>> hw/pci-host/uninorth.c | 2 +- >>>>> hw/ppc/mac_newworld.c | 14 +++++++------- >>>>> 2 files changed, 8 insertions(+), 8 deletions(-) >>>>> >>>>> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >>>>> index e72fe2a..21f805f 100644 >>>>> --- a/hw/pci-host/uninorth.c >>>>> +++ b/hw/pci-host/uninorth.c >>>>> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >>>>> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >>>>> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >>>>> 0x100000000ULL); >>>>> memory_region_init_alias(&d->pci_hole, OBJECT(d), >>>>> "pci-hole", &d->pci_mmio, >>>>> - 0x80000000ULL, 0x70000000ULL); >>>>> + 0x80000000ULL, 0x10000000ULL); >>>> >>>> Doesn't OpenBIOS need to know about this change so it can update >>>> its device tree? >>> >>> No. >> >> We don't expose the pci-hole size in device tree? > > We do but already as 0x10000000. See: > http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arch/ppc/qemu/init.c > Ugh. Please send a single patch that fixes this with a proper patch description indicating that OpenBIOS already exposes the pci hole with 0x10000000 size. > >>>>> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >>>>> &d->pci_hole); >>>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >>>>> index 4bdaa8d..a4e5044 100644 >>>>> --- a/hw/ppc/mac_newworld.c >>>>> +++ b/hw/ppc/mac_newworld.c >>>>> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState >>>>> *machine) >>>>> machine_arch = ARCH_MAC99; >>>>> } >>>>> /* init basic PC hardware */ >>>>> - pci_vga_init(pci_bus); >>>>> - >>>>> escc_mem = escc_init(0, pic[0x25], pic[0x24], >>>>> serial_hds[0], serial_hds[1], >>>>> ESCC_CLOCK, 4); >>>>> memory_region_init_alias(escc_bar, NULL, "escc-bar", >>>>> escc_mem, 0, >>>>> memory_region_size(escc_mem)); >>>>> - for(i = 0; i < nb_nics; i++) >>>>> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", >>>>> NULL); >>>>> - >>>>> - ide_drive_get(hd, MAX_IDE_BUS); >>>>> - >>>>> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >>>>> dev = DEVICE(macio); >>>>> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >>>>> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState >>>>> *machine) >>>>> macio_init(macio, pic_mem, escc_bar); >>>>> /* We only emulate 2 out of 3 IDE controllers for now */ >>>>> + ide_drive_get(hd, MAX_IDE_BUS); >>>>> + >>>>> macio_ide = >>>>> MACIO_IDE(object_resolve_path_component(OBJECT(macio), >>>>> "ide[0]")); >>>>> macio_ide_init_drives(macio_ide, hd); >>>>> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState >>>>> *machine) >>>>> } >>>>> } >>>>> + pci_vga_init(pci_bus); >>>>> + >>>>> if (graphic_depth != 15 && graphic_depth != 32 && >>>>> graphic_depth != 8) >>>>> graphic_depth = 15; >>>>> + for(i = 0; i < nb_nics; i++) >>>>> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", >>>>> NULL); >>>>> + >>>>> /* The NewWorld NVRAM is not located in the MacIO device */ >>>>> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >>>>> qdev_prop_set_uint32(dev, "size", 0x2000); >>>> >>>> I presume all the changes above only change the devfn ordering? >>> >>> It changes the addresses assigned to devices which is needed for >>> MorphOS to work as it hardcodes the mmio locations of some (actually >>> most) devices. >> >> I don't see how the ordering change here could possibly change MMIO >> locations for anything? > > It's how OpenBIOS assigns MMIO addresses to pci devices. It does it by > going through them in order and map them starting from the base > address (with some allingment). I guess you could look at > drivers/pci.c I think it's in there somewhere. I think it'd make more sense to just bolt the PCI devices to their respective devfns that they also have on real hardware. Depending on ordering magic that happens to give us different BAR maps by firmware doesn't really give me a lot of confidence. Alex
On Mon, 23 Jun 2014, Alexander Graf wrote: > On 17.06.14 12:24, BALATON Zoltan wrote: >> On Tue, 17 Jun 2014, Alexander Graf wrote: >>> On 17.06.14 11:36, BALATON Zoltan wrote: >>>> On Tue, 17 Jun 2014, Alexander Graf wrote: >>>>> On 12.04.14 11:20, BALATON Zoltan wrote: >>>>>> Bring the memory map closer to a PowerMac3,1 model by removing unused >>>>>> areas and adding the VGA and network cards after the macio to let the >>>>>> latter be mapped from 0x80000000 like on real hardware. (On real >>>>>> hardware the graphics and network cards are on separate buses but we >>>>>> don't model that yet.) >>>>>> >>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>>>> --- >>>>>> >>>>>> This patch is intended to bring memory layout closer to what's seen in >>>>>> these dumps: >>>>>> >>>>>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt >>>>>> http://raveland.org/ports/eeprom.txt >>>>>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html >>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 >>>>>> >>>>>> v2: Added back unin2_memory region that Darwin seems to like better >>>>>> >>>>>> --- >>>>>> hw/pci-host/uninorth.c | 2 +- >>>>>> hw/ppc/mac_newworld.c | 14 +++++++------- >>>>>> 2 files changed, 8 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c >>>>>> index e72fe2a..21f805f 100644 >>>>>> --- a/hw/pci-host/uninorth.c >>>>>> +++ b/hw/pci-host/uninorth.c >>>>>> @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, >>>>>> d = UNI_NORTH_PCI_HOST_BRIDGE(dev); >>>>>> memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", >>>>>> 0x100000000ULL); >>>>>> memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", >>>>>> &d->pci_mmio, >>>>>> - 0x80000000ULL, 0x70000000ULL); >>>>>> + 0x80000000ULL, 0x10000000ULL); >>>>> >>>>> Doesn't OpenBIOS need to know about this change so it can update its >>>>> device tree? >>>> >>>> No. >>> >>> We don't expose the pci-hole size in device tree? >> >> We do but already as 0x10000000. See: >> http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arch/ppc/qemu/init.c > > Ugh. Please send a single patch that fixes this with a proper patch > description indicating that OpenBIOS already exposes the pci hole with > 0x10000000 size. Sent to the list. >>>>>> memory_region_add_subregion(address_space_mem, 0x80000000ULL, >>>>>> &d->pci_hole); >>>>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >>>>>> index 4bdaa8d..a4e5044 100644 >>>>>> --- a/hw/ppc/mac_newworld.c >>>>>> +++ b/hw/ppc/mac_newworld.c >>>>>> @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState >>>>>> *machine) >>>>>> machine_arch = ARCH_MAC99; >>>>>> } >>>>>> /* init basic PC hardware */ >>>>>> - pci_vga_init(pci_bus); >>>>>> - >>>>>> escc_mem = escc_init(0, pic[0x25], pic[0x24], >>>>>> serial_hds[0], serial_hds[1], ESCC_CLOCK, >>>>>> 4); >>>>>> memory_region_init_alias(escc_bar, NULL, "escc-bar", >>>>>> escc_mem, 0, >>>>>> memory_region_size(escc_mem)); >>>>>> - for(i = 0; i < nb_nics; i++) >>>>>> - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>>>> - >>>>>> - ide_drive_get(hd, MAX_IDE_BUS); >>>>>> - >>>>>> macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); >>>>>> dev = DEVICE(macio); >>>>>> qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ >>>>>> @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) >>>>>> macio_init(macio, pic_mem, escc_bar); >>>>>> /* We only emulate 2 out of 3 IDE controllers for now */ >>>>>> + ide_drive_get(hd, MAX_IDE_BUS); >>>>>> + >>>>>> macio_ide = >>>>>> MACIO_IDE(object_resolve_path_component(OBJECT(macio), >>>>>> "ide[0]")); >>>>>> macio_ide_init_drives(macio_ide, hd); >>>>>> @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) >>>>>> } >>>>>> } >>>>>> + pci_vga_init(pci_bus); >>>>>> + >>>>>> if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth >>>>>> != 8) >>>>>> graphic_depth = 15; >>>>>> + for(i = 0; i < nb_nics; i++) >>>>>> + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); >>>>>> + >>>>>> /* The NewWorld NVRAM is not located in the MacIO device */ >>>>>> dev = qdev_create(NULL, TYPE_MACIO_NVRAM); >>>>>> qdev_prop_set_uint32(dev, "size", 0x2000); >>>>> >>>>> I presume all the changes above only change the devfn ordering? >>>> >>>> It changes the addresses assigned to devices which is needed for MorphOS >>>> to work as it hardcodes the mmio locations of some (actually most) >>>> devices. >>> >>> I don't see how the ordering change here could possibly change MMIO >>> locations for anything? >> >> It's how OpenBIOS assigns MMIO addresses to pci devices. It does it by >> going through them in order and map them starting from the base address >> (with some allingment). I guess you could look at drivers/pci.c I think >> it's in there somewhere. > > I think it'd make more sense to just bolt the PCI devices to their respective > devfns that they also have on real hardware. Depending on ordering magic that > happens to give us different BAR maps by firmware doesn't really give me a > lot of confidence. I don't understand what you mean. I don't want to rewrite PCI handling code in OpenBIOS as that would have a higher chance of breaking something else (OpenBIOS is used by other archs as well). Also it would require more knowledge about the emulated hardware in OpenBIOS while it aims to be a generic implementation and wants to reduce special cases already in it. So I don't see a cleaner and easy way to do this. If I'm missing something please tell me. On the other hand you've said before that the mac99 machine is mostly a hack to be enough that some OS-es can run with it. Why reordering some devices to get the right BAR maps not fit in this hack? Regards, BALATON Zoltan
On 23/06/14 20:25, BALATON Zoltan wrote: >>> It's how OpenBIOS assigns MMIO addresses to pci devices. It does it >>> by going through them in order and map them starting from the base >>> address (with some allingment). I guess you could look at >>> drivers/pci.c I think it's in there somewhere. >> >> I think it'd make more sense to just bolt the PCI devices to their >> respective devfns that they also have on real hardware. Depending on >> ordering magic that happens to give us different BAR maps by firmware >> doesn't really give me a lot of confidence. > > I don't understand what you mean. I don't want to rewrite PCI handling > code in OpenBIOS as that would have a higher chance of breaking > something else (OpenBIOS is used by other archs as well). Also it would > require more knowledge about the emulated hardware in OpenBIOS while it > aims to be a generic implementation and wants to reduce special cases > already in it. So I don't see a cleaner and easy way to do this. If I'm > missing something please tell me. On the other hand you've said before > that the mac99 machine is mostly a hack to be enough that some OS-es can > run with it. Why reordering some devices to get the right BAR maps not > fit in this hack? Since the MMIO address is calculated by rounding up to the next start address based on region size (where size tends to be more static compared to start address) then I'd be okay with this as a short term hack. Longer term I suspect we'll need to teach OpenBIOS about assigning fixed addresses to certain PCI devices based upon architecture, and it's starting to look like I may need to do this for the next part of my work on improving SPARC64 support. ATB, Mark.
On Mon, 23 Jun 2014, Mark Cave-Ayland wrote: > On 23/06/14 20:25, BALATON Zoltan wrote: > >>>> It's how OpenBIOS assigns MMIO addresses to pci devices. It does it >>>> by going through them in order and map them starting from the base >>>> address (with some allingment). I guess you could look at >>>> drivers/pci.c I think it's in there somewhere. >>> >>> I think it'd make more sense to just bolt the PCI devices to their >>> respective devfns that they also have on real hardware. Depending on >>> ordering magic that happens to give us different BAR maps by firmware >>> doesn't really give me a lot of confidence. >> >> I don't understand what you mean. I don't want to rewrite PCI handling >> code in OpenBIOS as that would have a higher chance of breaking >> something else (OpenBIOS is used by other archs as well). Also it would >> require more knowledge about the emulated hardware in OpenBIOS while it >> aims to be a generic implementation and wants to reduce special cases >> already in it. So I don't see a cleaner and easy way to do this. If I'm >> missing something please tell me. On the other hand you've said before >> that the mac99 machine is mostly a hack to be enough that some OS-es can >> run with it. Why reordering some devices to get the right BAR maps not >> fit in this hack? > > Since the MMIO address is calculated by rounding up to the next start address > based on region size (where size tends to be more static compared to start > address) then I'd be okay with this as a short term hack. Thanks. I've sent the other half of the patch then, that could be taken until a better solution will be available (it does not have to be reverted then either). Regards, BALATON Zoltan
diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c index e72fe2a..21f805f 100644 --- a/hw/pci-host/uninorth.c +++ b/hw/pci-host/uninorth.c @@ -230,7 +230,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic, d = UNI_NORTH_PCI_HOST_BRIDGE(dev); memory_region_init(&d->pci_mmio, OBJECT(d), "pci-mmio", 0x100000000ULL); memory_region_init_alias(&d->pci_hole, OBJECT(d), "pci-hole", &d->pci_mmio, - 0x80000000ULL, 0x70000000ULL); + 0x80000000ULL, 0x10000000ULL); memory_region_add_subregion(address_space_mem, 0x80000000ULL, &d->pci_hole); diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index 4bdaa8d..a4e5044 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -371,18 +371,11 @@ static void ppc_core99_init(MachineState *machine) machine_arch = ARCH_MAC99; } /* init basic PC hardware */ - pci_vga_init(pci_bus); - escc_mem = escc_init(0, pic[0x25], pic[0x24], serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); memory_region_init_alias(escc_bar, NULL, "escc-bar", escc_mem, 0, memory_region_size(escc_mem)); - for(i = 0; i < nb_nics; i++) - pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); - - ide_drive_get(hd, MAX_IDE_BUS); - macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); dev = DEVICE(macio); qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ @@ -393,6 +386,8 @@ static void ppc_core99_init(MachineState *machine) macio_init(macio, pic_mem, escc_bar); /* We only emulate 2 out of 3 IDE controllers for now */ + ide_drive_get(hd, MAX_IDE_BUS); + macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), "ide[0]")); macio_ide_init_drives(macio_ide, hd); @@ -418,9 +413,14 @@ static void ppc_core99_init(MachineState *machine) } } + pci_vga_init(pci_bus); + if (graphic_depth != 15 && graphic_depth != 32 && graphic_depth != 8) graphic_depth = 15; + for(i = 0; i < nb_nics; i++) + pci_nic_init_nofail(&nd_table[i], pci_bus, "ne2k_pci", NULL); + /* The NewWorld NVRAM is not located in the MacIO device */ dev = qdev_create(NULL, TYPE_MACIO_NVRAM); qdev_prop_set_uint32(dev, "size", 0x2000);
Bring the memory map closer to a PowerMac3,1 model by removing unused areas and adding the VGA and network cards after the macio to let the latter be mapped from 0x80000000 like on real hardware. (On real hardware the graphics and network cards are on separate buses but we don't model that yet.) Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> --- This patch is intended to bring memory layout closer to what's seen in these dumps: http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt http://raveland.org/ports/eeprom.txt http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134 v2: Added back unin2_memory region that Darwin seems to like better --- hw/pci-host/uninorth.c | 2 +- hw/ppc/mac_newworld.c | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-)