[CDG5] Rage128 NDRV

Mon Jul 29 13:32:00 AWST 2019

Hi all,

For context, Balaton and JD seem to be fixing up Qemu’s ?new Rage128 emulation to support MacOS. Max, copying you in because you know the Trampoline pretty well. Daniel, because you know a heap about OF and FCODE drivers. Mailing list, for posterity.

I think the Rage128 driver should be patched to get some log messages out of it. (The NK log is preferable to MacsBug because it can easily be extracted from Qemu, and because it is available earliest in boot.)

Plug #1: Getting printf spam out of PEFs is basically the main use case for...
https://github.com/elliotnunn/patchpef

The MacOS “Trampoline” boot loader, embedded in the “Mac OS ROM” bootinfo file, can patch PEF drivers into the device tree before the MacOS proper gets access to it. In this case, the ROM PEF never gets touched.

Plug #2: We can patch arbitrary drivers into a bootinfo file by using this dump/rebuild tool...
https://github.com/elliotnunn/tbxi

But the downloads you link to seem not to work. Anything on GitHub?

Elliot

> On 29 Jul 2019, at 7:01 am, BALATON Zoltan <balaton at eik.bme.hu> wrote:
> 
> Hello,
> 
> On Mon, 29 Jul 2019, Elliot Nunn wrote:
>> Unfortunately, the NK debugger is not useful for much more than dumping physical memory and internal kernel structures. MacsBug operates at the level that you want, but requires a working frame buffer. :(
> 
> There's a 3rd possibility which is to attach a debugger to QEMU when running with -s -S options which can be used to debug guest code but we would need to find addresses to break at. We can also look at what code is run with -d in_asm QEMU option so for someone who can understand how MacOS and NDRVs work that might give some info. I've tried to look at it but all I see is a lot of indexed loads and stores so it likely works with all kinds of structures so it's hard to trace back what is wrong in these without knowing these structures. I could not even find where it decided to stop.
> 
>> Is there a downloadable disk-based Rage128 driver? You might find some debug symbols in one.
> 
> JD had a few disk based NDRVs in some old ATI updates but I'm not sure where those are. I've only looked at NDRVs from FCode ROMs but those are stripped down to fit in ROM so does not log anything. Not sure if disk based NDRVs are more verbose or if there are any with debug symbols available.
> 
>> I did write a utility called “patchpef” a while back, which can add rudimentary instrumentation (including NK-based logging) to an arbitrary PEF. It isn’t very useful without debug symbols, though.
>> 
>> Can you send me a binary of this driver to have a look at?
> 
> I was trying the OEM Rage128Pro FCode ROMs from
> 
> http://themacelite.wikidot.com/wikidownloads2
> 
> Revision 110 and 136 from the top of the table, which should approximately match the emulated card and a 110 ROM dumped from a real machine with such card. These have the NDRV in them starting at the Joy! header with some FCode that installs it in device-tree. Unfortunately to run it in QEMU some QEMU and OpenBIOS patches are needed that are on the respective lists but not commited yet. Maybe in a few weeks they'll be upstream so it will be easier to reproduce it. Or maybe one can get same results with only testing NDRV via passing it with QEMU romfile option which OpenBIOS will add to device tree as NDRV but then some properties may be missing from device tree and I'm not sure if that would cause problems.
> 
> What I get with all appl,debug options enabled the last thing it does is trying to map the card's mmio bar to access registers I think:
> 
> Reset system - Into the 68K fire: 0000d032 6806e8c0
> ResetSystem trap entered
> Kernel code base at 0x00f10000  Physical RAM size 0x1fffc000 bytes
> Created motherboard coherence group. ID 00010001
> NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001
> Created system address space. ID 00030001
> BATs ffc0007f 00c00023   6800001f 00f00023   00000000 00000000   00000000 00000
> 000
> Nanodebugger activated.
> Init ready queue 00000000 00000000 00019603
> Init ready queue 00000001 00000000 000cb018
> Init ready queue 00000002 00000000 006580c0
> Init ready queue 00000003 00000000 032c0600
> System context at 0x1f7ff100  Vector save area at 0x1f7fb880  SDR1 0x1f80003f
> Adding blue task 00050001 to the ready queue
> Starting timeslicing
> Adding idle task 00070001 to the ready queue
> NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001
> Priming the system free list with 81 pages.
> VMMaxVirtualPages: 0005fffe VMLogicalPages: 0001f7c3
> Interrupt handler kind: 06
> Converting PMDTs to areas
> CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created
> CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created
> CreateArea [ 60c00000 60ffffff ] ID 000c0001 placed ... created
> CreateArea [ 64000000 6417ffff ] ID 000d0001 placed ... created
> CreateArea [ 68fef000 68feffff ] ID 000e0001 placed ... created
> CreateArea [ 68ff5000 68ffefff ] ID 000f0001 placed ... created
> CreateArea [ 68fff000 68ffffff ] ID 00100001 placed ... created
> CreateArea [ 80000000 8005ffff ] ID 00110001 placed ... created
> CreateArea [ 80060000 80060fff ] ID 00120001 placed ... created
> CreateArea [ 80061000 8007ffff ] ID 00130001 placed ... created
> CreateArea [ 80080000 80080fff ] ID 00140001 placed ... created
> CreateArea [ 81000000 81ffffff ] ID 00150001 placed ... created
> CreateArea [ 82000000 82003fff ] ID 00160001 placed ... created
> CreateArea [ f0000000 ffffffff ] ID 00170001 placed ... created
> CreateArea [ 68f16000 68f16fff ] ID 00180001 placed ... created
> CreateArea [ deadb000 deadbfff ] ID 00190001 placed ... created
> 
> The 81000000 is the rage128pro VRAM, the 82000000 is the mmio regs BAR. Then QEMU reports it tries some invalid SPRs. It is believed that MacOS detects the CPU with this so this is normal:
> 
> Trying to write privileged spr 955 (0x3bb) at 00f168c8
> Trying to write invalid spr 959 (0x3bf) at 00f16930
> Trying to read invalid spr 959 (0x3bf) at 00f16938
> 
> Then continues
> 
> Reset system - Into the 68K fire: 0002d032 6806c9e8
> Extend free pool: phys 0x1ffbf000  virt 0x00000000  count: 1
> 
> At this point it tries to read something that's missing on QEMU:
> 
> Unassigned mem read 00000000ff004000
> Unassigned mem read 00000000ff006000
> Unassigned mem read 00000000ff004000
> Unassigned mem read 00000000ff004001
> Unassigned mem read 00000000ff004002
> [...]
> Unassigned mem read 00000000ff005ffc
> Unassigned mem read 00000000ff005ffd
> Unassigned mem read 00000000ff005ffe
> Unassigned mem read 00000000ff005fff
> 
> Then at this point it invokes the NDRV which starts poking the card:
> 
> 3646 at 1564333468.477426:ati_mm_read 4 0x104 CONFIG_APER_1_BASE -> 0x81000000
> 3646 at 1564333468.477475:ati_mm_read 4 0x104 CONFIG_APER_1_BASE -> 0x81000000
> 3646 at 1564333468.477480:ati_mm_read 4 0x10c CONFIG_REG_1_BASE -> 0x82000000
> 3646 at 1564333468.477500:ati_mm_write 4 0xe0 CNFG_CNTL <- 0x0
> 3646 at 1564333468.477527:ati_mm_write 4 0x30 BUS_CNTL <- 0x71b3a340
> 3646 at 1564333468.477560:ati_mm_write 4 0x34 BUS_CNTL1 <- 0x1f
> 3646 at 1564333468.477564:ati_mm_write 4 0x58 DAC_CNTL <- 0xff000102
> 3646 at 1564333468.477569:ati_mm_write 4 0xf0 GEN_RESET_CNTL <- 0x0
> 3646 at 1564333468.477573:ati_mm_write 4 0x130 unknown <- 0x2054
> 
> This goes on setting basic parameters, then reading EDID from the two connectors of the card then ends with trying to get mmio regs I think but no register reads or writes happen after that so something went wrong here (I think it may also look at the ROM BAR of the card but not sure):
> 
> 3646 at 1564333469.743518:ati_mm_read 4 0x110 CONFIG_REG_APER_SIZE -> 0x4000
> 3646 at 1564333469.743527:ati_mm_read 4 0x10c CONFIG_REG_1_BASE -> 0x82000000
> VMMakePageCacheable for I/O 00082000
> VMMakePageCacheable for I/O 00082001
> VMMakePageCacheable for I/O 00082002
> VMMakePageCacheable for I/O 00082003
> Extend free pool: phys 0x1ffbe000  virt 0x00000000  count: 2
> Extend free pool: phys 0x1ffbd000  virt 0x00000000  count: 3
> Extend free pool: phys 0x1ffbc000  virt 0x00000000  count: 4
> Extend free pool: phys 0x1ffbb000  virt 0x00000000  count: 5
> Extend free pool: phys 0x1ffba000  virt 0x00000000  count: 6
> Extend free pool: phys 0x1ffb9000  virt 0x00000000  count: 7
> Extend free pool: phys 0x1ffb8000  virt 0x00000000  count: 8
> Extend free pool: phys 0x1ffb7000  virt 0x00000000  count: 9
> Extend free pool: phys 0x1ffb6000  virt 0x00000000  count: 10
> 
> (The ati_mm_* lines are from QEMU, the others from MacOS). I think it does continue and boots to desktop but I can't see it because FCode has switched mode but the driver is not init so picture will not be correct.
> 
> The problem is I don't know if the emulation is correct (very likely not) and how it should behave so it's hard to tell why it's failing and what the NDRV expect. There could be all kinds of differences and missing pieces that could give the NDRV unexpected input that makes it fail. Currently the emulation is very preliminary (works with Linux framebuffer and MorphOS but not much else yet) the point of this excercise is to find out what else would be needed to get it working with MacOS (probably a lot as the ATI drivers likely would use all details these cards have and they have quite a few layers gathered through their evolution from ATI VGAwonder chips to Radeons).
> 
> Maybe we should get such capture from real hardware to see where it goes after that when it works and if we see any more logs afterwards that could hint at where it stops. Unfortunately we don't see the register reads and writes on real hardware as we do on QEMU. Is there a way to put some kind of watch points to mmio areas so we can get mmio activity to the gfx card on real machine?
> 
> Regards,
> BALATON Zoltan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190729/10aee751/attachment.htm 