On Sun, 22 Jan 2023, BALATON Zoltan wrote:
On Mon, 29 Jun 2020, BALATON Zoltan wrote:
This is now a minimal set of patches needed to make it possible to
experiment with a firmware ROM from real hardware. After finding out
that the board firmware does not probe PCI devices but expects them at
known fixed addresses we only need to change the address of the macio
device to get the firmware correctly map it. This allows dropping
workarounds in previous versions for this and now only the minimal set
of patches are included to get the firmware loaded and do something.
(Also excluded the grackle revision and machine ID pathes for now that
may be needed as the firmware accesses these but seems to go further
without them so until we hit a problem we can live without it,
although I wonder if this causes us unnecessary debugging later so
unless they cause regressions they could be merged).
I still don't get video output but at least it talks to the GPU chip
now so it can be debugged and improved (this will either need
emulating the correct chip the firmware has a driver for or an OF
compliant ROM for the emulated card).
As before the I2C part (patches 6-8) is RFC and unfinished but the
first 5 patches should be good enough now. I hope someone can take
care of I2C, I can look at the ati-vga side later.
Regards,
BALATON Zoltan
BALATON Zoltan (8):
mac_oldworld: Allow loading binary ROM image
mac_newworld: Allow loading binary ROM image
mac_oldworld: Drop a variable, use get_system_memory() directly
mac_oldworld: Drop some variables
mac_oldworld: Change PCI address of macio to match real hardware
i2c: Match parameters of i2c_start_transfer and i2c_send_recv
Continuing experimenting with getting g3beige work with the original firmware
ROM here's the current status. The above patches were already merged.
WIP macio/cuda: Attempt to add i2c support
mac_oldworld: Add SPD data to cover RAM
Adding these last two patches on top of Mark's screamer branch and increasing
SCREAMER_BUFFER_SIZE define to 0x8000 in include/hw/audio/screamer.h to avoid
a crash and using -memory 256 (as RAM size detection seems to be broken maybe
due to imcomplete I2C emulation) I get the ROM to start but it cannot yet
boot. We're past the initial OpenFirmware setup, can get a Forth prompt and
explore the device tree and run Forth and also can start the Toolbox ROM from
/AAPL,ROM but then it stops somewhere in there without giving any log or diag
output. I think it may be waiting for some interrupt or missing some of the
Heathrow emulation but I'm not really sure. I can get these traces:
heathrow_write 0x28 1: 0x80000000
heathrow_read 0x24 1: 0x80000000
heathrow_read 0x2c 1: 0x0
heathrow_write 0x18 0: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_read 0x1c 0: 0x0
heathrow_write 0x28 1: 0x80000000
heathrow_read 0x24 1: 0x80000000
heathrow_read 0x2c 1: 0x0
heathrow_write 0x18 0: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_read 0x1c 0: 0x0
portA_write unimplemented
portA_write unimplemented
heathrow_read 0x24 1: 0x80000000
heathrow_write 0x24 1: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_write 0x14 0: 0x0
heathrow_read 0x24 1: 0x80000000
heathrow_write 0x24 1: 0x80040000
heathrow_set_irq set_irq: num=0x12 level=1
heathrow_write 0x28 1: 0x80000000
heathrow_read 0x24 1: 0x80040000
heathrow_read 0x2c 1: 0x40000
heathrow_write 0x18 0: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_read 0x1c 0: 0x0
heathrow_write 0x28 1: 0x80000000
heathrow_read 0x24 1: 0x80040000
heathrow_read 0x2c 1: 0x40000
heathrow_write 0x18 0: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_read 0x1c 0: 0x0
heathrow_write 0x28 1: 0x80000000
heathrow_read 0x24 1: 0x80040000
heathrow_read 0x2c 1: 0x40000
heathrow_write 0x18 0: 0x80000000
heathrow_read 0x14 0: 0x0
heathrow_read 0x1c 0: 0x0
Adding some cuda* traces and info via output in case that helps to tell
what's happening:
portA_write unimplemented
cuda_delay_set_sr_int
cuda_delay_set_sr_int
cuda_packet_send length 5
cuda_packet_send_data [0] 0x00
cuda_packet_send_data [1] 0x40
cuda_packet_send_data [2] 0x2c
cuda_packet_send_data [3] 0xa4
cuda_packet_send_data [4] 0xff
cuda_delay_set_sr_int
portA_write unimplemented
heathrow_set_irq set_irq: num=0x12 level=1
(qemu) info via
mos6522-cuda:
Registers:
ORB : 0x30
ORA : 0x10
DDRB: 0x30
DDRA: 0x58
T1CL: 0x11
T1CH: 0x14
T1LL: 0xff
T1LH: 0xff
T2CL: 0x1b
T2CH: 0x88
SR : 0xff
ACR : 0x1c
PCR : 0x0
IFR : 0x60
IER : 0x20
Timers:
Using current time now(ns)=33052813591
T1 freq(hz)=783333 mode=one-shot counter=0x1411 latch=0xffff
load_time(ns)=0 next_irq_time(ns)=33131055374
T2 freq(hz)=1276 mode=one-shot counter=0x881b latch=0x30c
load_time(ns)=257468378 next_irq_time(ns)=33349161167
then the last 6 lines are repeating endlessly. Does anybody have an idea what
these registers are doing and where they are implemented in QEMU? The model
in hw/intc/heathrow_pic.c seems to be very simple but I'm not sure how are
these connected to the rest of the mac_oldworld g3beige machine. I've checked
that the IRQ numbers defined in include/hw/misc/macio/macio.h seems to match
what's in the device tree generated by the ROM but there are some missing
devices we don't emulate (such as SWIM floppy, PMAC ethernet and MESH SCSI).
Yet the above looks like IRQ 0x12 is raised which should be CUDA and there
were some portA write errors before that so maybe something with VIA or CUDA
emulation? Any insight on this anyone?
Regards,
BALATON Zoltan
hw/display/sm501.c | 2 +-
hw/i2c/core.c | 34 +++++++-------
hw/i2c/ppc4xx_i2c.c | 2 +-
hw/misc/macio/cuda.c | 76 ++++++++++++++++++++++++++++++-
hw/ppc/mac.h | 2 -
hw/ppc/mac_newworld.c | 22 +++++----
hw/ppc/mac_oldworld.c | 86 +++++++++++++++++++++++-------------
include/hw/i2c/i2c.h | 4 +-
include/hw/misc/macio/cuda.h | 1 +
9 files changed, 167 insertions(+), 62 deletions(-)
