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(-)
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
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(-) > >
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(-)
>>
>>
>
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.
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
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
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
© 2016 - 2024 Red Hat, Inc.