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

BALATON Zoltan posted 8 patches 1 week ago
Test FreeBSD passed
Test docker-quick@centos7 passed
Test checkpatch passed
Test docker-mingw@fedora passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/cover.1593456926.git.balaton@eik.bme.hu
Maintainers: BALATON Zoltan <balaton@eik.bme.hu>, Corey Minyard <cminyard@mvista.com>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, David Gibson <david@gibson.dropbear.id.au>
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(-)

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

Posted by BALATON Zoltan 1 week ago
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
  WIP macio/cuda: Attempt to add i2c support
  mac_oldworld: Add SPD data to cover RAM

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

-- 
2.21.3


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

Posted by Mark Cave-Ayland 1 week ago
On 29/06/2020 19:55, 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.

If you can sort out the issue with masking in patches 1 and 2 then I'd be happy to
take patches 1-5. Obviously there is still some discussion around the i2c part, so I
can wait a few more days to see what the outcome is there: the patches generally seem
okay, the one change I would like to see is to add a comment around the SPD parts
mentioning that these are only used by the real G3 ROM and not OpenBIOS.

My only concern is whether an incomplete i2c implementation could cause OSs that
currently boot to hang, so it is important that you can test a variety of OS images
from MacOS to Linux and BSD to ensure that it doesn't cause any regression.


ATB,

Mark.

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

Posted by Howard Spoelstra 1 week ago
If you can sort out the issue with masking in patches 1 and 2 then I'd be
> happy to
> take patches 1-5. Obviously there is still some discussion around the i2c
> part, so I
> can wait a few more days to see what the outcome is there: the patches
> generally seem
> okay, the one change I would like to see is to add a comment around the
> SPD parts
> mentioning that these are only used by the real G3 ROM and not OpenBIOS.
>
> My only concern is whether an incomplete i2c implementation could cause
> OSs that
> currently boot to hang, so it is important that you can test a variety of
> OS images
> from MacOS to Linux and BSD to ensure that it doesn't cause any regression.
>
>
Hi, I tested this patch set both on top of current master and on top of
Mark' screamer branch.

On top of master with mac99 machine
MacOS:
HD boot: all 9.x and all 10.X boot to desktop
CD boot: all 9.x and all 10.X boot to installer
Linux:
HD boot: Fedora 12, Debian 4, Debian Squeeze
CD boot: Debian 10, Lubuntu-16.04 Live boots to desktop
Freebsd tested (Live CD only)
CD boot only: 12.1 boots to black screen (terminal shows: call-method
set-depth failed with error ffffffdf) 11.4 boots to root login.

On top of master with g3beige machine
MacOS:
HD boot: 10.0,10.1 boot to desktop
Linux:
HD boot: Fedora 12 boots to graphical login screen then hangs

On top of screamer branch with mac99 machine
MacOS:
HD boot: 9.0 and 9.1 often hang with audio extension error. 9.2 and all
10.X boot to desktop. Nothing new here.
CD boot: all 9.x and all 10.X boot to installer
Linux:
HD boot: Debian 4 boots to failing X server
CD boot: Lubuntu-16.04 boot to desktop

On top of screamer branch with g3beige machine:
MacOS:
HD boot: 10.0, 10.1 boot to desktop.
CD boot: 10.0 to 10.4 boot to installer
Linux:
HD boot: Fedora 12 boots to graphical login screen then hangs

All in all, I see no regressions.
The boing is beautiful when g3beige/screamer with increased buffer size
boots the G3 rom ;-)

Best,
Howard

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

Posted by BALATON Zoltan 1 week ago
On Thu, 2 Jul 2020, Howard Spoelstra wrote:
> The boing is beautiful when g3beige/screamer with increased buffer size
> boots the G3 rom ;-)

Try it without my RFC I2C patches (checkout the one before i2c which is 
"mac_oldworld: Change PCI address of macio to match real hardware" then 
build that). With that a crashing sound is heard and you get > prompt 
where you can type ? to see a hardware test menu (but most tests don't 
seem to return anything useful and the ROM checksum is failing, seems to 
read from wrong address). I've shown that here:

https://lists.nongnu.org/archive/html/qemu-ppc/2020-06/msg00239.html

I've never seen that on real hardware but I don't have much experience 
with old Macs. I guess you'd get the same if you removed all RAM from a 
machine and connected a serial terminal (in case you have a real beige 
G3). This might also be useful to test emulation if someone wants to 
investigate.

Regards,
BALATON Zoltan

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

Posted by BALATON Zoltan 1 week ago
On Tue, 30 Jun 2020, Mark Cave-Ayland wrote:
> On 29/06/2020 19:55, 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.
>
> If you can sort out the issue with masking in patches 1 and 2 then I'd be happy to

Patch 2 does not have masking only patch 1, I'll try to have a look and 
reply to that message.

> take patches 1-5. Obviously there is still some discussion around the i2c part, so I
> can wait a few more days to see what the outcome is there: the patches generally seem

The fix to i2c API would be welcome (not sure it will be resolved in a few 
days but we'll see) but it's not the main problem that makes patch 7 RFC. 
Rather the hardcoded returning 5 bytes in cuda_cmd_combined_iic() which is 
probably not how CUDA should work (apart from that I'm also not sure 
cuda_cmd_get_set_iic() is correct) but

1. I don't know how CUDA works
2. Don't have time and interest in larger CUDA model refactoring

so I've only made the changes needed to be able to test the ROM and 
identify what needs to be fixed. This CUDA I2C is one thing that someone 
with more knowledge/interest may want to look at in more detail. If 
there's nobody to make a better patch now maybe we can test if this breaks 
anything and once the I2C API changes settle down I can rebase it as it 
is, maybe also removing i2c attempts from cuda_cmd_get_set_iic() only 
leaving a log there is better as that command only seems to be used to 
access not yet emulated devices and always returns error at the moment 
anyway not reaching any of the i2c calls in there (I think it may be the 
audio mixer device the ROM tries to poke with this command but I'm not 
sure, I've also seen another i2c address, could be some sensor?, maybe 
DingusPPC has some info on these i2c devices but haven't checked it). 
Anyway, this i2c part is not urgent and can come back to it later. If we 
get in the first 5 patches now that would clean my tree sufficiently to 
only leave patches I intend to change later and get rid of the finished 
ones so I have less patches piling up.

> okay, the one change I would like to see is to add a comment around the SPD parts
> mentioning that these are only used by the real G3 ROM and not OpenBIOS.

This patch also has a dependency on spd_data_generate() API that probably 
won't get fixed before the freeze unless I submit a patch but not sure 
I'll have time for that, also it's not useful without the previous I2C 
patch so again we can see where this goes and come back to it with the I2C 
part.

> My only concern is whether an incomplete i2c implementation could cause OSs that
> currently boot to hang, so it is important that you can test a variety of OS images
> from MacOS to Linux and BSD to ensure that it doesn't cause any regression.

I neither have these images nor time to test all of them so I hoped you 
could do this as part of your merge testing or someone else can help out 
here with testing.

Regards,
BALATON Zoltan