English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   68030, 68040 and 68060 MMU support (really!) (http://eab.abime.net/showthread.php?t=46934)

gilgamesh 30 August 2009 11:17

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 30 August 2009 12:34

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 30 August 2009 14:21

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 30 August 2009 16:13

Quote:

Originally Posted by Toni Wilen (Post 589785)
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 30 August 2009 16:19

Quote:

Originally Posted by jotd (Post 589852)
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 :)

Quote:

Originally Posted by Boo Boo (Post 589889)
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 30 August 2009 16:36

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

My curiosity has been piqued by this development too. :)


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

gilgamesh 30 August 2009 21:42

Quote:

Originally Posted by Toni Wilen (Post 589827)
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
Code:

amiboot-5.6 -d -k vmlinux.tmp -r root_d.bin root=/dev/ram
The root image contains /sbin/init. I tried to add
Code:

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 30 August 2009 21:54

Quote:

Originally Posted by gilgamesh (Post 590012)
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 31 August 2009 20:18

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 31 August 2009 20:24

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 01 September 2009 17:38

Quote:

Originally Posted by gilgamesh (Post 590297)
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..

Quote:

Originally Posted by jotd (Post 590298)
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 01 September 2009 21:34

1 Attachment(s)
Quote:

Originally Posted by Toni Wilen (Post 590565)
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.

Attachment 22552

bye

gilgamesh 01 September 2009 21:54

1 Attachment(s)
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 02 September 2009 08:19

Quote:

Originally Posted by jotd (Post 590650)
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 02 September 2009 17:25

Quote:

Originally Posted by gilgamesh (Post 590659)
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 02 September 2009 18:51

Quote:

Originally Posted by Toni Wilen (Post 590739)
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 02 September 2009 20:48

Quote:

Originally Posted by Toni Wilen (Post 590859)
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 :rolleyes, 68040+MMU, 2MB chip+64MB Z3, Debian Woody.

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

Toni Wilen 02 September 2009 21:45

Quote:

Originally Posted by gilgamesh (Post 590936)
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.

Quote:

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 03 September 2009 17:20

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

gilgamesh 03 September 2009 22:32

1 Attachment(s)
Quote:

Originally Posted by Toni Wilen (Post 591277)
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.


All times are GMT +2. The time now is 02:50.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.08794 seconds with 11 queries