Re: Emulated macppc with qemu
Michael <[email protected]> Tue, 6 Apr 2021 00:32:26 -0400
| Newsgroups | gmane.os.netbsd.ports.macppc |
|---|---|
| Organization | The NetBSD Foundation |
| Message-ID | <20210406003226.17205568@pi400> |
Hello, On Mon, 5 Apr 2021 10:16:00 -0700 Jason Thorpe <[email protected]> wrote: > > On Apr 5, 2021, at 9:30 AM, Michael <[email protected]> wrote: > > > > This caught my eye a bit late, but... > > How is >2GB RAM supposed to work on even an emulated 32bit macppc? > > The address space is divided up by hardware into 0x0 - 0x7fffffff for > > RAM, and above that lives PCI space, various onboard devices and > > firmware ROMs. If you map extra RAM into this range NetBSD will need > > adjustments since we BAT-map most of this space 1:1. > > That said, it shouldn't be hard to get this working, just have to pay > > more attention when entering BAT mappings, and the RAM counting code > > may ignore areas above 0x80000000. > > Right, this is what I meant in my previous message. The physical > memory map on G4 Macs doesn't have room for more than 2G of RAM. .. or any other that I know of. Even on G5s the 32bit range looks like a 32bit mac, with any additional RAM appearing above 4GB. > Mark -- it might be a good idea to place a limit of 2G in the 32-bit > Mac emulation. In theory it would be possible to emulate a weirdo mac with RAM in the lower 3GB and PCI space above that, I don't think any of our code actually depends on mac-io ( and therefore openpic etc. ) living at 0x80000000 - if the OF tree said it's at 0xc0000000 that part would probably Just Work(tm)... Now of course I don't know if that's what qemu does or if it actually supports such a thing in the first place. have fun Michael