From: BALATON Zoltan <balaton@eik.bme.hu>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1
Date: Tue, 17 Jun 2014 12:24:47 +0200 (CEST) [thread overview]
Message-ID: <alpine.LMD.2.02.1406171215050.2477@jedlik.phy.bme.hu> (raw)
In-Reply-To: <53A00CD3.7000201@suse.de>
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
next prev parent reply other threads:[~2014-06-17 10:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 23:12 [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1 BALATON Zoltan
2014-06-09 20:26 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-16 23:37 ` BALATON Zoltan
2014-06-17 8:46 ` [Qemu-devel] " Alexander Graf
2014-06-17 9:36 ` BALATON Zoltan
2014-06-17 9:39 ` Alexander Graf
2014-06-17 10:24 ` BALATON Zoltan [this message]
2014-06-22 9:14 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-23 16:27 ` [Qemu-devel] " Alexander Graf
2014-06-23 19:25 ` BALATON Zoltan
2014-06-23 21:33 ` Mark Cave-Ayland
2014-06-23 22:32 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LMD.2.02.1406171215050.2477@jedlik.phy.bme.hu \
--to=balaton@eik.bme.hu \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).