68030, 68040 and 68060 MMU support (really!)

[gilgamesh]

Yeah, Hypercom runs smoothly now (tested with Slink).
But then it stops stops after "RAMDISK: Compressed image found at block 0".
It takes a long time (several minutes), "VFS: Mounted root (ext2 filesystem)" and after that "Kernel panic: No init found".

Maybe this is an configuration error on my side? Strange.

[Toni Wilen]

For some unknown reason root.bin mounted as ramdisk does not contain /sbin/init (or working filesystem or something)

Someone with more emulated Linux interest than me should do some debugging..

[jotd]

Toni this is great! I quickly tested your 68040 MMU and found out that it works for access faults within WHDLoad !!
That's great news, thanks.

[Retro1234]

Originally Posted by Toni Wilen

Use A1200 or A4000 like configuration (IDE). Your screenshot shows A3000 SCSI used without being enabled (and it does not work very well even if you enable it)

Thanks ill have another go, I was haveing some problems with HDF's with IDE controller, but ill have another play.

[Toni Wilen]

Originally Posted by jotd

Toni this is great! I quickly tested your 68040 MMU and found out that it works for access faults within WHDLoad !!
That's great news, thanks.

Perfect

Originally Posted by Boo Boo

Thanks ill have another go, I was haveing some problems with HDF's with IDE controller, but ill have another play.

Make sure you have correct IDE controller enabled in advanced chipset or select correct "chipset extra" Amiga model in chipset-panel. (A1200/A600 IDE is not same as A4000 IDE), also select matching KS ROM (for example A4000 ROM without A4000 IDE will freeze during boot)

[prowler]

Thanks for your continuing work on this aspect of Amiga emulation, Toni!

My curiosity has been piqued by this development too.


Edit: ...and thanks thanks for the configuration hints.

[gilgamesh]

Originally Posted by Toni Wilen

For some unknown reason root.bin mounted as ramdisk does not contain /sbin/init (or working filesystem or something)

Someone with more emulated Linux interest than me should do some debugging..

I didn't solve the problem, but came one step closer (using Woody).
You need much more ram than I thought. Install 32MB Z3 at least or more. (I use 128MB.)

root.bin and linux.bin are compressed (gz). Uncompress them in order to save time. You can mount the uncompressed root image under (native) linux. It is ext2.
Edit StartInstall so that it will use the uncompressed images. Something like

amiboot-5.6 -d -k vmlinux.tmp -r root_d.bin root=/dev/ram

The root image contains /sbin/init. I tried to add

init=/sbin/init

but amiboot does not pass init to the kernel as a parameter. I think everything would be fine, if it did.
EDIT: Or it does pass it, and something goes completely wrong at lowlevel.

[Toni Wilen]

Originally Posted by gilgamesh

EDIT: Or it does pass it, and something goes completely wrong at lowlevel.

Exactly, something goes wrong. Parameter is not needed if (and in this case it is) init is located in root partition.

[gilgamesh]

Well, this is somewhat beyond everything that I've done before.

I might be able to check whether the image on ramdisk is the same as the original, using UAE's internal debugger.

At least some portions of the root image must have been copied properly (magic number, at least one inode). Otherwise /dev/ram couldn't be mounted.

Does anybody around here have another idea what to do?

[jotd]

Toni small problem here: MMU seems to work only with 24 bit configurations. In 32 bit mode it's not working: access faults are not detected.

[Toni Wilen]

Originally Posted by gilgamesh

Well, this is somewhat beyond everything that I've done before.

I might be able to check whether the image on ramdisk is the same as the original, using UAE's internal debugger.

At least some portions of the root image must have been copied properly (magic number, at least one inode). Otherwise /dev/ram couldn't be mounted.

Does anybody around here have another idea what to do?

It probably is something really simple but really difficult to find, perhaps some very rarely used 68020+ instruction combined with MMU fails to work correctly..

Originally Posted by jotd

Toni small problem here: MMU seems to work only with 24 bit configurations. In 32 bit mode it's not working: access faults are not detected.

Try http://www.winuae.net/files/b/winuae.zip . You have to be much more specific if it still does not work, "not work" isn't a bug report as usual

[jotd]

Originally Posted by Toni Wilen

Try http://www.winuae.net/files/b/winuae.zip . You have to be much more specific if it still does not work, "not work" isn't a bug report as usual

Ok, sorry for the infuriating "it does not work" report.
I re-did the test with the new version: whdload has protected all memory besides 0-$80000 and yet when I try to access $81000 it works without access fault: MMU seems not enabled here (same behaviour as with the versions without MMU), at least the address boundary protection.
My config has 32 bit fastmem (not possible to save states). When I do that on a 24 bit config memory (to use savestates) I get a neat "access fault" from Whdload, witnessing that MMU is working in that case.



bye

[gilgamesh]

Ha, Toni's latest patch resolved the ramdisk problem, too.

But now there is trouble with the block-major-3 device. That's DH0, isn't it? Errno ist 14.
See for yourself:

[Toni Wilen]

Originally Posted by jotd

Ok, sorry for the infuriating "it does not work" report.
I re-did the test with the new version: whdload has protected all memory besides 0-$80000 and yet when I try to access $81000 it works without access fault: MMU seems not enabled here (same behaviour as with the versions without MMU), at least the address boundary protection.
My config has 32 bit fastmem (not possible to save states). When I do that on a 24 bit config memory (to use savestates) I get a neat "access fault" from Whdload, witnessing that MMU is working in that case.

I'd like to know what exactly are you doing because this isn't 32 bit problem, I can cause access faults easily with enforcer active using 32 bit ram. This is either aligment or instruction problem.

EDIT: to make this less confusing, what is the exact instruction that should have caused access violation but didn't? Including all registers and status register.

[Toni Wilen]

Originally Posted by gilgamesh

Ha, Toni's latest patch resolved the ramdisk problem, too.

But now there is trouble with the block-major-3 device. That's DH0, isn't it? Errno ist 14.
See for yourself:

I can't duplicate this, still not working here

This really does seem to point in some kind of address alignment or similar problem.

[jotd]

Originally Posted by Toni Wilen

I'd like to know what exactly are you doing because this isn't 32 bit problem, I can cause access faults easily with enforcer active using 32 bit ram. This is either aligment or instruction problem.

EDIT: to make this less confusing, what is the exact instruction that should have caused access violation but didn't? Including all registers and status register.

I'm trying to dump area $81000 which is valid in the amiga memory, but not in the WHDLoad memory, which marks other zones as invalid => on real amiga or on a given config (24 bit mem) access fault is triggered.

I'll create a test slave which writes to $81000, it will be simpler.

[gilgamesh]

Originally Posted by Toni Wilen

I can't duplicate this, still not working here

This really does seem to point in some kind of address alignment or similar problem.

I checked this again.
The ramdisk error does not happen when the kernel and root image are decompressed. This behaviour is new since your last update.
When they are compressed, the usual error does still happen.

I'll see whether I can recompile the kernel and add some error checking...
Btw, Sarge still has illegal instruction issues.

My current config is 1200, KS3.0, WB1.3 , 68040+MMU, 2MB chip+64MB Z3, Debian Woody.

P.S.: http://people.debian.org/~cts/debian-m68k/ Interesting...

[Toni Wilen]

Originally Posted by gilgamesh

I checked this again.
The ramdisk error does not happen when the kernel and root image are decompressed. This behaviour is new since your last update.
When they are compressed, the usual error does still happen.

I am not so sure because I uncompressed both few days ago. No change.

Btw, Sarge still has illegal instruction issues.

This is fixed in next beta. One variant of MOVES was buggy. Not that it helps much, illegal instruction only changes to our favorite "no init" error

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip now includes MOVES fix. (I am still getting no init error..)

[gilgamesh]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.zip now includes MOVES fix. (I am still getting no init error..)

Now, that is strange. Sarge works for me, starts init, and then fails to unmount some filesystem. I make a slow but steady progress in the boot process, while you still hang with the init issue. I wonder why.

EDIT: Woody starts five processesover and over again. The init and mount issues are gone here. Packed images aren't problematic either.