X-Surf on A3000, SoftRoms 3.2.1 setpatch

jbbolcato · Apr 30th 2022

Hi guys,

Very odd - my X-Surf which is working fine on my 68030 A3000 under AmigaOS and Roms (superkickstart) 3.1, refuses to get recognised when I update my system to AmigaOS and Roms (superkickstart) 3.2.1.

I have to manually skip setpatch in the startup sequence for it to work, as that way it then leaves disabled all burst/cache/mmu features of the 68030.

Running the "xsurftest" command without setpatch at boot, the card works and gets me online nicely with either Roadshow or Miami.

But if I let the A3000 boot normally with setpatch, the card seems found by xsurftest, but fails the 16bit ram test? see pics.

See pic included.

Any idea? It seems DataCache/Mmu related!

I saw in the download page I need to disable the data cache on 68030. But trying to do that with setpatch doesn't work (Setpatch NOCACHE still leaves them on), and doing it with the cpu command (NODATACACHE) afterwards, to match what I get without setpatch, doesn't help. Same error in xsurftest.

Reverted back to 3.1, it seems to work even with Setpatch and Data caches on, I get a slightly different error on the ram test (which advises to remove the cache) but it works anyway!

So maybe it's more the default MMU setup in 3.2.1?

I realise it's potentially in Hyperion's court to fix this, but wanted to know what you guys think, and any info I can pass Hyperion would be helpful to narrow things down.

Cheers,

JBB

thebajaguy · May 1st 2022

I think getting the state of the MMU / cache settings against the I/O space may be helpful. Use MuScan (if not in the lite version with 3.2.1, get the full version of MuLibs from Aminet). The address space where the X-Surf is placed should be set in a non-cache mode address space. I'd put this in Thor's court if it's mis-set.

To modify the MMU settings for a specific address region or card, you will have to pull out the MuLibs manual to use the MuSetCacheMode command, or update the config file in the EnvArc: area.

jbbolcato · May 1st 2022

Many thanks for your suggestion.

I didn't have any Thor's MMU libs installed on either system, so both 3.1 and 3.2.1 were respectively generic Commodore or Hyperion memory & cpu lib toolset.

I installed Thor's libs first on my simple WB3.1 & softRom3.1 config (which I came back to, as it was working!) - just to get the MuScan tool running. Rebooted.

Then I run MuScan, it shows what's on the attached screenshot.

Seems pretty messy with some invalid entries? Is that expected? (sorry for silly questions)

The area the Xsurf uses (x40000000) seems to be flagged as I/O space invalid... is that supposed to be listed as that in order to protect the area for it?

I tried Xsurftest right after: the Xsurf 16bit memory isn't recognised (PIOWriteMem Timeout) with a big stall of like 10s.

Trying Miami, it stalls in a worse manner (I cannot move the mouse cursor for like 20s) and then errors and fails to find the Xsurf (Unable to open Sana-II device popup). Even fully crashed on me once, never recovered. Had to power off/on.

That was after a fresh boot, and if I run MuScan BEFORE XsurfTest, or Miami.

If I run XsurfTest and Miami BEFORE running MUscan, the Xsurf 16bit memory is fine and tests ok. XSurf is recognised by Miami and I can go online smoothly.

But running MUscan afterwards gives the same report, and then I get the stalls again.

So definitely something fishy with MMU setup, and the way it behaves once scanned by Thor's MuScan?!

Note my Amiga is a base A3000-68030-25Mhz, Buster11, 8MB Fast Ram, 2 MB chip Ram, superkickstart roms. The only zorro card in there is the Xsurf. It is rock solid super stable with 3.1. Until I installed the MMU Libs and started fiddling with MuScan that it!

So frustrating!

I'll try to do a similar report using WB3.2.1/softRom3.2.1 (easy to do with a superkickstart 3000)

BTW could it be the reason? the fact that my Rom is in Ram? (I know MMU tools can do similar things)

Cheers,

JBB

thebajaguy · May 1st 2022

The X-Surf area at $4000.0000 should be marked CacheInhibit, and not what is in there. That will be your issue as it needs to be a valid non-cached address space.

"I/O Space" is normally just a readability label. The swapped position with the word "Invalid" is interesting, but I think the latter is still the state of the address region.

SuperKickstart does add a layer of complexity. It has to use the MMU to load/enable and keep the soft Kickstart active during a reboot, but then apply your 'fresh' booted system's memory space needs each time.

MuScan just reports the state of the MMU's table. Modifications are made with the MuSetCacheMode. You also program the initial setup state of the MMU when SetPatch loads and enables the library/MMU configuration from the config file in EnvArc: That file also has some commented out sections and configuration option detail (if present). Otherwise it uses CPU library defaults.

jbbolcato · May 2nd 2022

Wow! Ok, will drill deeper into mmu configuration docs and see if I can manually edit this.

Note I re-installed 3.2.1 on top of a clean 3.1 without mmu libs installed, this time taking special care to install the mmu disk from Hyperion with the special A3000 modules.

Sadly Xsurf still mishebaves, not recognised with the memory fail.

But MuScan gives different results, with less invalid stuff - see attached screenshot. Still not saying "Cache Inhibit" for x4000000, but "Blank I/O space" instead. I assume similar issue?

Again, if I skip setpatch in the startup, Xsurf works fine.

Many thanks for taking the time to respond to me! Cheers,

thebajaguy · May 2nd 2022

I would assume the SuperKickstart boot and MMU configuration is a corner case that is difficult to test without real hardware in hand.

If you notice the next address section, which covers the address space all the way to 0xFFFF.FFFF, know that the entire upper 2GB of address space (from 0x8000.0000) is 'off limits', or in other words, does not exist and cannot be used as far as the Amiga OS memory map is concerned. Hence, Blank is not a good sign.

I plugged my XSurf-100 into my A3000, and it places my board at the same address space as yours.

I am getting 0x40000000 - 0x4000FFFF CacheInhibit I/O Space

That is typical of an I/O board. I believe the command line you want to match that (for testing) is:

MuSetCacheMode from 0x40000000 size 0x10000 CacheInhibit Valid IO

If that works out, you can likely modify one of the video board entries like the first VA2000 line in ENVARC: MMU-Configuration to instead recognize product 4626 100. The parameters {base} and 0x10000 look like a match for this situation.

That's my guess - and if it works, the board can move to a new address with other expansion added, but not need any adjustments. I can't say the same for any additional boards in your case. Save a copy of the working config so that you have a reference if an updated MuLibs comes out.

jbbolcato · May 2nd 2022

Wow, you're a lifesaver man - works beautifully. Many thanks for trying the same config as me and confirming/suggesting that.

Actually added this to my MMU-Configuration, after checking the other lines in there:

for 4626 100 Z3 SetCacheMode {base} {size} Valid CacheInhibit IOSpace

As the card seems partially autoconfig, the base and size should be fed with the right things in case it moves due to another card coming in.

And indeed my MuScan lists the same as you now, and the Xsurf gets recognised, with its 16bit ram working ok, and Miami is happy.

Many thanks for this!!!

Now, any idea why my A3000 had this entry in the MMU config as invalid (on 3.1) and blank (on 3.21), and yours was happily reserving it nicely?

Anyway, hope this helps someone else down the line! not many articles out there on how to edit MMU configs, it is scary at first!

Cheers,

JBB

Jens · May 2nd 2022

All this should not be required - the latest X-Surf-100 driver should automatically find the MMU lib and mark the space as "cache inhibit".

Note that xsurftest is an engineering tool. You should not run it while the card is in use, and you should not attempt to open the device after the test program has run, because it leaves the computer in an unknown (=not clean) state. Reboot recommended

jbbolcato · May 2nd 2022

Interesting. Well, it didn't do it automatically on my A3000 - could it be because I started using it without MMU at first install boot/first few days, I had to disable it as setpatch was crashing on startup due to some glitch in my libs installation. So I was running with a bare 68030 and no recent libs like Thor's. Then I got around to reinstall it properly with the update3.2.1 disks done properly step by step.

The xsurf install process only consists of copying the x-surf.device in the right place (devs/Networks)... there is no installer or obvious first time setup - so bit unsure at what point the mmu config gets tweaked by the driver? At every boot? At every time the device gets used? First time only?

Anyway, doing it manually resolved the problem, and I'm good to go!!

Good to know about xsurftest - it was doing some unreliable things once used indeed. BTW had to download an older version of the driver to find that tool. Any particular reason it's not available for download officially as a engineering/debug tool? It was very useful for me to realise the memory was not recognised and pointed us to a mmu misconfig.

Anyway thanks bajaguy and Jens for your support!

Note the Xsurf is now coexisting nicely with a BigRam+256 also from iComp! Keep up the good work guys.

JBB

thebajaguy · May 2nd 2022

For a system comparison, I'm using an A3000D, 3.2 ROMs and OS, 16MB / 2MB, A3640 w/060 Rev 1, , and the 2x wait state removal GALs. It has Buster-11. Mulibs: MuLibs 68060.library 46.5, mmu.library 46.22, I do MuMove4K during S:StartupSequence, and in S:User-Startup I enable FastROM , MuFastZero with FastExec and MoveSSP, and MuFastChip. An AmigaNet (Z2) board is the normal networking interface in the system on the third slot down. No other cards normally. I put the X-Surf 100 in the top slot when I tested it.

In my mind, about the only thing that might be out of the ordinary is the SuperKickstart soft-load state of the machine. It adds a level of complexity as the Kickstart loads and is MMU-protected, then soft-reboots into that new code, re-performing AutoConfig but having an MMU state from the previous boot. As to why it set it like it did, I'm not the right person at this point. I wasn't aware of the X-Surf-100 driver being MuLibs aware, either, and supposedly updating it's cache status. I didn't load any driver for the X-Surf - I only used the ShowConfig and MuScan tools output. I defer to Thor and Jens at this point. That you have it working is good.

Jens · May 3rd 2022

Quote from jbbolcato

so bit unsure at what point the mmu config gets tweaked by the driver? At every boot? At every time the device gets used?

If mmu lib is present, it's instructed to switch off data cache in the IO area of the X-Surf-100. At least that's what I remember; Timm will be able to confirm, he did the last changes to the driver. TBH, I'm not 100% sure about the MMU stuff.

Quote from jbbolcato

BTW had to download an older version of the driver to find that tool. Any particular reason it's not available for download officially as a engineering/debug tool?

Last changes included making separate versions for X-Surf-500 and X-Surf-100, and since it's an engineering tool, only required in exceptional cases, usually after talking back to support here, it's better to keep the driver package free from distractions. Imagine the amount of support cases that we have to handle when people first run the test, don't reboot and get weird behaviour after launching the TCP/IP stack: The more likely outcome is that we get more support cases with the tool than without.

Timm · May 3rd 2022

Quote from Jens

If mmu lib is present, it's instructed to switch off data cache in the IO area of the X-Surf-100. At least that's what I remember; Timm will be able to confirm, he did the last changes to the driver. TBH, I'm not 100% sure about the MMU stuff.

No, we employ a different solution - data caches are freezed on affected machines for short sections if and when needed. Indeed, this works fine with A3000/030, it doesn't require mmu.library, and was faster IIRC.

Timm · May 3rd 2022

I just tested an A3000/030 with a X-Surf-100 and OS3.2 (v47.7) installed.

I installed mmu.library from Aminet (v47.4).

I'm using our AmiTCP package and x-surf-100.device v1.16.

Network works like a charm.

The only possible differences would be the exact versions of OS3.2 and mmu.library.

Or have I missed something?

jbbolcato · May 3rd 2022

Many thanks for checking your config Timm & thebajaguy.

Very weird indeed - I too have v47.7 for OS3.2.1, but the MMU libs are v46.21 (installed by OS3.2.1), and Xsurf v1.16.

Do you have superkickstart A3000 too Timm, or physical roms in there... that could be the difference like thebajaguy mentioned.

I'll try to install the very latest Mmu, see if it makes any difference.

Anyway, it works!!! that's the main thing. Until next time! (A3660 on the way, may misbehave again!!)

Cheers guys,

JBB

thebajaguy · May 4th 2022

Quote from jbbolcato

(A3660 on the way, may misbehave again!!)

You will have to give up your SuperKickstart load system with anything higher than a 68030 CPU.

You will want 3.1.4 (at the lowest) for a 68060 compatibility with Kickstart. You may as well get the 3.2 or 3.2.1 ROM burned if you plan to run with the latest Amiga OS.

jbbolcato · May 4th 2022

Good to know, I read that somewhere a while back so I did order some physical 3.2.1. roms alongside my CD/files!

Thanks for confirming my suspicion... will be sad to lose the flexibility, but the extra speed will help me forget...

Cheers!

JBB

Timm · May 4th 2022

Just for the record, the A3000 I am testing with are not with SuperKickstart, but with 3.1 ROMs.