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

[BALATON Zoltan]

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