This patchset is aimed at unifying the code used to preserve CPU context
when switching from client programs into Forth, via either the CIF or
It is part of a longer process to enable access to saved CPU context state
from within Forth which will eventually enable proper implementation of the
init-program and go words.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (8):
SPARC64: create proper stack frame when entering client interface
SPARC64: introduce new Forth context stack (fcstack) for CPU contexts
SPARC64: switch client interface over to use new Forth context stack
SPARC64: switch IMMU/DMMU miss handlers over to use new Forth context
SPARC64: move client interface stack inline to the new Forth context
SPARC64: move IMMU/DMMU miss handler stacks inline to the new Forth
SPARC64: reorganise IMMU/DMMU trap context structure
SPARC64: rearrange saved state window order
openbios-devel/arch/sparc64/call-client.S | 218 +++++----------------
openbios-devel/arch/sparc64/context.c | 4 +
openbios-devel/arch/sparc64/cpustate.h | 244 +++++++++++++++++++++++
openbios-devel/arch/sparc64/ldscript | 5 +
openbios-devel/arch/sparc64/vectors.S | 300 ++++++-----------------------
openbios-devel/include/arch/sparc64/io.h | 2 +-
6 files changed, 367 insertions(+), 406 deletions(-)
create mode 100644 openbios-devel/arch/sparc64/cpustate.h
On 24/11/15 09:01, Alfonso Gamboa wrote:
> These images are definitely helpful, however what would be really useful
> to know is exactly what the modules in question do:
> - Multiprocessing (maybe uses a currently unimplemented CPU instruction
> to facilitate faster multitasking?)
> - Open Transport ASLM Modules (no idea what these do)
> - Apple Audio Extension Module (is this just a standard sound driver or
> other? I did get a backtrace once suggesting that it was trying to
> access digital CDROM audio which is why it crashed. Then again if it
> thinks that the CDROM is a HD then that's not going to help too much
> here either).
> The "Multiprocessing" folder contains a file named "Apple CPU Plugins"
> of type cpup. Looking at the resource "cpups", it seems to contain code
> to supplement the OS to support various newer CPUs and architectures.
> The resources in the file are named (and contain):
> "hammerhead" (old clone computers based off multiple PPC 604I believe)
Now the mac99 machine defines itself as "PowerMac3,1" so that might
suggest that it is something in the keylargo/uni-north code that is
causing the problem. Is there a way to somehow disable the individual
resources in the Core99Plugin in order to determine which one is the
> The "Open Transport ASLM Modules" file seem to be a collection of shared
> libraries, since many programs, once this file is removed from the
> extensions folder, refuses to run, for example Apple System Profiler.
> OTLib$NBPScnr, OTLib$SerIAB are some examples of shared libraries
> contained within this file. This is verified from the book "Sad Macs,
> Bombs, and Other Disasters: And what to Do about Them By Ted Landau
> , see https://goo.gl/TVm9Tt"
> I will do more research.
A good starting point is the "Apple Audio Extension Module" since that
seems to cause havoc on load. Do you know any good tutorials on how to
debug an extension module on load i.e. how to step through its
initialisation? Unfortunately there doesn't seem to be much related
documentation around these days.
On 24/11/15 05:23, Alfonso Gamboa wrote:
> Here are some links I packaged for the emaculation forum, included is an
> image with macsbug installed already. I had success booting to desktop.
> Note: it seems as time goes by, booting several times using the ISO
> images corrupts them, resulting in failed boots with crashes at the boot
> splash screen. Crashes will continue until you replace them with fresh
> ones from the zip files. Reasons as to why are unknown at this time.
Yeah I noticed when booting from a CDROM that my open windows are
remembered across sessions(!). This makes me think that OS 9 thinks the
HFS volume is a HD rather than a CDROM and so mounts it read/write on
boot. How would I find this out in OS9?
> Resedit, Stuffit, Toast, Disk Copy, utilities in an ISO to mount within
> MacOS 9.2.2 bootable image(extensions all removed):
> MacOS 9.2.1 bootable image(extensions all removed):
> MacOS 9.2.1 bootable image with macsbug (extensions all removed):
These images are definitely helpful, however what would be really useful
to know is exactly what the modules in question do:
- Multiprocessing (maybe uses a currently unimplemented CPU instruction
to facilitate faster multitasking?)
- Open Transport ASLM Modules (no idea what these do)
- Apple Audio Extension Module (is this just a standard sound driver or
other? I did get a backtrace once suggesting that it was trying to
access digital CDROM audio which is why it crashed. Then again if it
thinks that the CDROM is a HD then that's not going to help too much
On 20/11/15 17:06, Alfonso Gamboa wrote:
> booting into MacOS9 with qemu to the Desktop is now possible, see:
> Some issues, remain, certain extensions crash on boot.
Has there been any progress at all as to which extensions may be causing
openbios fails to build with gcc 5.2 cross compilers. This is using fedora 23
packages. There's a bug here with complete info:
The error is:
powerpc64-linux-gnu-gcc $EXTRACFLAGS -m32 -msoft-float -fno-builtin-bcopy
-fno-builtin-log2 -Os -g -DNATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH
-USWAP_ENDIANNESS -Wall -Wredundant-decls -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels
-Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes -Wnested-externs
-Werror -MMD -MP -MT target/arch/ppc/qemu/ofmem.o -MF
-I/root/openbios/openbios-1.1/kernel/include -I./target/include -c -o
/tmp/ccznzzOd.s: Assembler messages:
/tmp/ccznzzOd.s:551: Error: missing operand
rules.mak:309: recipe for target 'target/arch/ppc/qemu/ofmem.o' failed
make: *** [target/arch/ppc/qemu/ofmem.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/root/openbios/openbios-1.1/obj-ppc'
Makefile:32: recipe for target 'subdir-ppc' failed
make: *** [subdir-ppc] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.DSB86j (%build)
David Howells' commented in the bug with a suggested fix... but I don't even
have a setup to test openbios so I'd prefer if someone else cooks up the patch :)
On Fri, 20 Nov 2015, Alfonso Gamboa wrote:
> booting into MacOS9 with qemu to the Desktop is now possible, see:
> On Nov 20, 2015 7:46 AM, "Programmingkid" <programmingkidx(a)gmail.com> wrote:
>> I use to have the same belief until Mark set me straight. We are only
>> making an emulator of a new world Mac, not a simulator of a PowerMac3,1.
>> This means we might be able to get away with not exactly mirroring a real
>> Mac. The fact that Mac OS 9 can boot up at all does give me hope we are on
>> the right path.
I'm clear on that but what I've meant was that we probably have to make a
closer emulation of the real PowerMac (not one to one but close enough) to
make OSes written for that hardware happy. I think we are missing some i2c
and gpio emulation that these OSes might expect but I'm not sure.
One thing that might help to hint at what's missing is to compile QEMU
with DEBUG_UNASSIGNED (this will generate a lot of logs) and try to find
out what is accessed that is not emulated.
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_a...
and this device tree:
PowerMac G4 device tree
This series of patches allows to build openbios on a
powerpc64 host. It has been tested with the following targets:
ppc, sparc32, sparc64. It has also been tested on x86_64 host
with the same targets.
v2: remove patches 3/5 and 4/5 of the first series and replace it
with patch 4/4. We don't include the system includes using
full pathname but use '-iquote' intead of '-I'
A preliminary patch is needed for fcode-utils, as "toke" is
broken on big endian architecture:
diff -ru fcode-utils/toke/scanner.c fcode-utils-new/toke/scanner.c
--- fcode-utils/toke/scanner.c 2006-10-30 09:48:28.000000000 +0100
+++ fcode-utils-new/toke/scanner.c 2015-10-19 00:21:43.417373690 +0200
@@ -1625,7 +1625,7 @@
void user_message( tic_param_t pfield )
- char delim = (char)pfield.deflt_elem ;
+ char delim = (char)pfield.fw_token ;
handle_user_message( delim, TRUE);
@@ -5295,7 +5295,7 @@
void process_remark( tic_param_t pfield )
- char until_char = (char)pfield.deflt_elem ;
+ char until_char = (char)pfield.fw_token ;
unsigned int start_lineno = lineno;
Laurent Vivier (4):
switch-arch: factorize code to compute architecture properties.
switch-arch: compute base arch and allow native compiler for 32bit
switch-arch: as for powerpc64, select sparc64 compiler to compile
bootstrap: don't include files from target/include as system includes.
Makefile.target | 2 +-
config/scripts/switch-arch | 85 +++++++++++++++++++++++++---------------------
include/arch/ppc/types.h | 8 -----
3 files changed, 48 insertions(+), 47 deletions(-)