Re: [PATCH v7 0/8] Mac Old World ROM experiment

[BALATON Zoltan]

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

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(-)