From: Brad Boyer <flar@allandria.com>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Debian m68k <debian-68k@lists.debian.org>
Subject: Re: Using more than 1 GB in qemu-m68k-system
Date: Sat, 14 Dec 2019 17:41:34 -0800 [thread overview]
Message-ID: <20191215014133.GA2084@allandria.com> (raw)
In-Reply-To: <alpine.LNX.2.21.1.1912150919080.8@nippy.intranet>
On Sun, Dec 15, 2019 at 09:36:33AM +1100, Finn Thain wrote:
> I believe that the reason for the limitation is the Mac memory map, as
> Laurent pointed out in the issue tracker,
> https://github.com/vivier/qemu-m68k/issues/42
>
> It's theoretically possible to use NuBus slot space for additional RAM.
>
> The super slot space ($6000 0000 thru $EFFF FFFF) is 2304 MB in size and
> the standard slot space ($F100 0000 thru $FFFF FFFF) is another 239 MB.
>
> I'm not sure about any hardware designs that took advantage of this
> possibility (Radius Rocket perhaps?).
On the fundamental issue, yes the Mac uses $0000 0000 to $3FFF FFFF for
RAM, with $4000 0000 the start of ROM and $5000 0000 the start of the
internal devices.
The Radius Rocket does have RAM, but I never checked if it was visible
from the host. It seems like it should be to do a few of the things
it does. I've never tried to poke at mine while in Linux. I'll add it
to the list of things to try. Even then, it would be slower than the
RAM directly on the processor bus.
We could probably emulate a fake NuBus card in qemu that is just memory
in the super slot space for that card. Can a regular driver add RAM, or
would we have to detect that in the core code somewhere?
Brad Boyer
flar@allandria.com
next prev parent reply other threads:[~2019-12-15 2:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-14 20:20 Using more than 1 GB in qemu-m68k-system John Paul Adrian Glaubitz
2019-12-14 22:36 ` Finn Thain
2019-12-15 1:41 ` Brad Boyer [this message]
2019-12-15 11:01 ` Geert Uytterhoeven
2019-12-17 0:26 ` Finn Thain
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=20191215014133.GA2084@allandria.com \
--to=flar@allandria.com \
--cc=debian-68k@lists.debian.org \
--cc=fthain@telegraphics.com.au \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-m68k@lists.linux-m68k.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).