Sonnet 7200 PCI programming

[trixster]

This is the cache ram

[grelbfarlk]

Originally Posted by trixster

This is the cache ram

That is a 200MHz part, correct size. So that's not a problem.

For anyone having random crashes make sure that you are not running Tinymeter, it's a crashfest when there's a PPC installed.

[spudje]

Things are not getting clearer. Cowcat's Quake runs fine windowed in 060, both with and without the -ahi option. I did run copymem060 first, no clue whether that is something that makes stuff more stable?

So I'm so puzzled what the reason is for my crashes in both Sonnet and CSPPC setup. I'm gonna try Quake 1 in PPC mode now. And I think I'm gonna make a bare CSPPC setup instead my ClassicWB CSPPC setup.

[spudje]

Mmm, are there separate 68k and PPC AHI binaries?

When I run Cowcat's PPC/WOS Quake on my Sonnet setup I get a PPC exception (see attachment) when I don't add the -ahi option. When I run the WOS binary on the Sonnet with ahi I get the same crash after some minutes as I get with Wipeout & Quake 2.

Makes me wonder that my ahi is maybe only failfree on 68k?

OK, I see two AHI binaries on my Mediator MM CD:
- 5.6 for m68k
- 5.7 for PPC

So how do I setup a system that uses the PPC binary when running PPC software and uses the m68k binary when running m68k software. It looks like I can only pick one of the two?

[Hedeon]

No AHI means crash in a lot of games because the Sonnet cannot access Amiga Hardware directly. There is still something trying to access CHIP RAM from the PPC. I see 0x9e30 in r11/DAR which is CHIP and 0xdff000 in r10 which are the hardware registers.

There is no WarpOS AHI. PPC is only for MorphOS/OS4. You need the 68k version.

Did you do a screenshot also of the crash with -ahi?

[spudje]

Just tried with ahi 6.0, but same result, glquakewos crashes after a bout 15 minutes in a freeze with a sound loop. No crash report I can share here. I'm really running out of ideas now. I can check the other version numbers, e.g. Picasso was one of the libs with a different version number than you guys had.

Update: I tried Wipeout in Windowed mode in Sonnet setup (284, setcmemdiv = 4) and got a PPC exception (which is I think the same thing that happens when in full screen but then not presented due to full freeze).

BTW who of you Hedeon, grelbfarlk & trixster is running MMUlibs? If you all are I guess I should try with that too.

[trixster]

I'm using MMULibs with 68060.library 46.3 and mmu.library 46.12

I'm using ahi.device 4.18, paula.audio is 4.23

[Hedeon]

Using the same stuff as Trixster. Btw srr0 in your screen shot is the program counter. So something is jumping to $0.

[grelbfarlk]

Originally Posted by spudje

Just tried with ahi 6.0, but same result, glquakewos crashes after a bout 15 minutes in a freeze with a sound loop. No crash report I can share here. I'm really running out of ideas now. I can check the other version numbers, e.g. Picasso was one of the libs with a different version number than you guys had.

Update: I tried Wipeout in Windowed mode in Sonnet setup (284, setcmemdiv = 4) and got a PPC exception (which is I think the same thing that happens when in full screen but then not presented due to full freeze).

BTW who of you Hedeon, grelbfarlk & trixster is running MMUlibs? If you all are I guess I should try with that too.

I'm using MMULibs. Did you test your AHI installation with AmigaAMP or Amplifier? Or WarpSNES?

[spudje]

Yes I tried Amplifier, worked ok.

Originally Posted by Hedeon

Using the same stuff as Trixster. Btw srr0 in your screen shot is the program counter. So something is jumping to $0.

Meaning, and what can I do about it?

[spudje]

Originally Posted by Hedeon

Before you do that....
1) Download the mulibs archive from THOR (on Aminet).
2) Just manually install the mmu.library in libs:
3) Restart the Amiga and start without startup-sequence
4) Execute Setpatch and the program called MuScan (from the archive).
5) Check if the PCI memory range is indicated as cache inhibited (see the 512MB Mediator range in ShowConfig).

If so, just add MuScan <>NIL: or something like that to the start of the startup-sequence (after SetPatch). This then initializes the mmu.library during startup which sets the MMU correctly.

Here I go again, mr n00b.

So I guess I should exactly do as you say, start it after a full boot of the Amiga and not directly from a cold power up. Because if I do it from a cold powerup the following happens: After setpatch the machine does a reboot and if I don't want it to freeze I need to skipromupdates scsi.device. If I after the setpatch reboot again start without startup-sequence muscan complains I haven't run setpatch.

So if I first let AOS 3.9 boot, including the BB2 ROM update and the setpatch SKIPROMUPDATES scsi.device. And only after that do a reboot without startup-sequence and first run setpatch (without arguments) and muscan I get the following showconfig result. I have no clue how to identify "PCI memory range is indicated as cache inhibited"

PROCESSOR: CPU 68060/68060fpu/68060mmu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 45.57, Exec version 45.20, Disk version 45.3
RAM: Node type $A, Attributes $505 (FAST), at $8000000-$FF7FFFF (127.5 meg)
Node type $A, Attributes $505 (FAST), at $7000000-$7FFFFFF (16.0 meg)
Node type $A, Attributes $405 (FAST), at $70000000-$7FFFFFFF (256.0 meg)
Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
Board (Index Information Ltd): Prod=2206/161($89E/$A1)
(@$40000000, size 512meg, subsize same)
Board (Index Information Ltd): Prod=2206/33($89E/$21)
(@$60000000, size 16meg, subsize same)
RAM (unidentified): Prod=3643/32($E3B/$20)
(@$70000000, size 256meg, subsize autosized Mem)
Board (Omega Datentechnik): Prod=2145/200($861/$C8) (@$E90000 64K)
Board + ROM (HD?) (phase 5): Prod=8512/100($2140/$64) (@$F01060 128K)

[trixster]

What does muscan show?

I believe the Mediator pci memory range starts at $40000000 according to your showconfig

[Hedeon]

Originally Posted by spudje

After setpatch the machine does a reboot and if I don't want it to freeze I need to skipromupdates scsi.device. If I after the setpatch reboot again start without startup-sequence muscan complains I haven't run setpatch.

Isn't this strange in itself? I mean, the Amiga should reboot on the first SetPatch (I forgot that happens with standard 3.1 KS ROMs; I got all the stuff in the ROM myself). But the second time it shouldn't, otherwise you would get infinite rebooting. So boot up a second time without startup-sequence, do the same SetPatch stuff. It shouldn't reboot now as it already has installed the resident stuff the first time, it now only installs e.g. the 060/AGA stuff, then run MuScan.

And it freezes immediately if you let it update scsi.device? Isn't that abnormal? Anyone else has thoughts on that?

Originally Posted by spudje

I have no clue how to identify "PCI memory range is indicated as cache inhibited"

Then you post it for us to see :-)

[Hedeon]

Originally Posted by spudje

Yes I tried Amplifier, worked ok.



Meaning, and what can I do about it?

Tells me something is not right, but cannot tell what. So I cannot tell you what to do.

In the 68K world, this mostly means an uninialized pointer. Here, I'm not so sure as the crash is not immediate, but after a certain amount of time.

[spudje]

Originally Posted by Hedeon

Tells me something is not right, but cannot tell what. So I cannot tell you what to do.
In the 68K world, this mostly means an uninialized pointer. Here, I'm not so sure as the crash is not immediate, but after a certain amount of time.

So in software most likely, not a hardware issue?

Originally Posted by Hedeon

Isn't this strange in itself? I mean, the Amiga should reboot on the first SetPatch (I forgot that happens with standard 3.1 KS ROMs; I got all the stuff in the ROM myself). But the second time it shouldn't, otherwise you would get infinite rebooting. So boot up a second time without startup-sequence, do the same SetPatch stuff. It shouldn't reboot now as it already has installed the resident stuff the first time, it now only installs e.g. the 060/AGA stuff, then run MuScan.

And it freezes immediately if you let it update scsi.device? Isn't that abnormal? Anyone else has thoughts on that?

Then you post it for us to see :-)

Originally Posted by trixster

What does muscan show?
I believe the Mediator pci memory range starts at $40000000 according to your showconfig

The skip scsidevice has got something to do with me needing IDE-fix if I remember correctly. (http://www.gregdonner.org/os39faq/installtips.html)

I tried the following now:
Powerup Amiga, start without s-s, setpatch SKIPROMUPDATES scsi.device, Amiga reboots
Start again without s-s, run setpatch (without skipromupdates, no reboot), run muscan.

Muscan:

MuScan 46.1 (02.07.2016) © THOR

68060 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x00000FFF CopyBack Remapped to 0x082B7000
0x00001000 - 0x00003FFF CacheInhibit Bundled to 0x080A3000
0x00004000 - 0x001FFFFF CacheInhibit Imprecise
0x00200000 - 0x00BBFFFF CacheInhibit Bundled to 0x080A3000
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF CacheInhibit Bundled to 0x080A3000
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00E8FFFF CacheInhibit Bundled to 0x080A3000
0x00E90000 - 0x00E9FFFF CacheInhibit I/O space
0x00EA0000 - 0x00EFFFFF CacheInhibit Bundled to 0x080A3000
0x00F00000 - 0x00F00FFF CacheInhibit
0x00F01000 - 0x00F21FFF CacheInhibit I/O space
0x00F22000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF CopyBack
0x01000000 - 0x06FFFFFF CacheInhibit Bundled to 0x080A3000
0x07000000 - 0x0802EFFF CopyBack
0x0802F000 - 0x08031FFF CacheInhibit
0x08032000 - 0x080A2FFF CopyBack
0x080A3000 - 0x080A3FFF CacheInhibit Imprecise
0x080A4000 - 0x080E6FFF CacheInhibit
0x080E7000 - 0x080F6FFF CopyBack
0x080F7000 - 0x080FEFFF CacheInhibit
0x080FF000 - 0x08101FFF CopyBack
0x08102000 - 0x08182FFF CacheInhibit
0x08183000 - 0x081A3FFF CopyBack
0x081A4000 - 0x082AEFFF CacheInhibit
0x082AF000 - 0x0FF7FFFF CopyBack
0x0FF80000 - 0x0FFFFFFF CacheInhibit
0x10000000 - 0x3FFFFFFF CacheInhibit Bundled to 0x080A3000
0x40000000 - 0x60FFFFFF CacheInhibit I/O space
0x61000000 - 0x6FFFFFFF CacheInhibit Bundled to 0x080A3000
0x70000000 - 0x7FFFFFFF CopyBack
0x80000000 - 0xFFEFFFFF CacheInhibit Bundled to 0x080A3000
0xFFF00000 - 0xFFF7FFFF CacheInhibit
0xFFF80000 - 0xFFFF7FFF CacheInhibit Bundled to 0x080A3000
0xFFFF8000 - 0xFFFFFFFF CopyBack Remapped to 0x082AF000

Showconfig:

PROCESSOR: CPU 68060/68060fpu/68060mmu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 45.57, Exec version 45.20, Disk version 45.3
RAM: Node type $A, Attributes $505 (FAST), at $8000000-$FF7FFFF (127.5 meg)
Node type $A, Attributes $505 (FAST), at $7000000-$7FFFFFF (16.0 meg)
Node type $A, Attributes $405 (FAST), at $70000000-$7FFFFFFF (256.0 meg)
Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
Board (Index Information Ltd): Prod=2206/161($89E/$A1)
(@$40000000, size 512meg, subsize same)
Board (Index Information Ltd): Prod=2206/33($89E/$21)
(@$60000000, size 16meg, subsize same)
RAM (unidentified): Prod=3643/32($E3B/$20)
(@$70000000, size 256meg, subsize autosized Mem)
Board (Omega Datentechnik): Prod=2145/200($861/$C8) (@$E90000 64K)
Board + ROM (HD?) (phase 5): Prod=8512/100($2140/$64) (@$F01060 128K)

[grelbfarlk]

Originally Posted by Hedeon

Isn't this strange in itself? I mean, the Amiga should reboot on the first SetPatch (I forgot that happens with standard 3.1 KS ROMs; I got all the stuff in the ROM myself). But the second time it shouldn't, otherwise you would get infinite rebooting. So boot up a second time without startup-sequence, do the same SetPatch stuff. It shouldn't reboot now as it already has installed the resident stuff the first time, it now only installs e.g. the 060/AGA stuff, then run MuScan.

And it freezes immediately if you let it update scsi.device? Isn't that abnormal? Anyone else has thoughts on that?



Then you post it for us to see :-)

Usually if you have anything other than the default scsi.device in the KS 3.1 ROM you'll get a couple recoverable alerts when it tries to load the 43.43 scsi.device on top of it. Don't know what happens if you have IDEFix installed other than it is supposed to detect that and skip updating the scsi.device.

If you are loading scsi.device 43.45 (or 46) from loadresident or loadmodule you'd want to skip the scsi.device in setpatch.

[Hedeon]

Originally Posted by spudje

So in software most likely, not a hardware issue?

Still most likely.

Originally Posted by spudje

The skip scsidevice has got something to do with me needing IDE-fix if I remember correctly. (http://www.gregdonner.org/os39faq/installtips.html)

IDE-Fix isn't loaded when you start without startup-sequence. So it shouldn't interfere like this. (Can someone tell me otherwise?)

Originally Posted by spudje

Muscan:

Looks correct. Proceed to the step beyond point number 5 (putting MuScan in your s-s, see above for the details).

[spudje]

Great, thanks, I'll continue later this week!

The scsi.device issue starts happening after applying BB2 and I think it actually hangs when IDEfix is loaded, not on running setpatch the 2nd time after reboot. My initial description wasn't clear, what I did wrong first was not run setpatch again after the (without s-s) reboot. But I'm pretty sure all this is unrelated to the Warp3D/PPC issues I have

[fgh]

Didn't read all of this, but OS3.9 BB2 has a bug in scsi.device v43.43 that results in a freeze/guru after setpatch reboot with all >4G devices which report LBA48 capability.
Try v43.45

Edit:
And idefix crashes with all 'removable' type devices, it can be patched, or you can use just atapi.device (part of idefix package) if second IDE channel only has atapi devices connected. (CD/DVD)

[spudje]

@fgh, thanks!!! That sounds like some helpful info. Where can I find that scsi.device version? And do I simply put it in devs and setpatch will use it?