68030, 68040 and 68060 MMU support (really!)

[Fackamato]

Cool, I'm following this thread.

Could anyone upload what's needed (the amiga linux hdf or whatever, compressed) somewhere?

[gilgamesh]

Installation doesn't work properly yet. You need an ISO of Debian for m68k (e.g. Sarge or Woody) and the latest WinUAE beta. Mount the ISO's contents as dh0 in UAE and boot them from WB shell. You can find the links and commands in this thread.

[Fackamato]

Originally Posted by gilgamesh

Installation doesn't work properly yet. You need an ISO of Debian for m68k (e.g. Sarge or Woody) and the latest WinUAE beta. Mount the ISO's contents as dh0 in UAE and boot them from WB shell. You can find the links and commands in this thread.

Yeah cool. I haven't messed with Amiga stuff (WinUAE) in a year, a lot has changed .

Did manage to get the same error (Usage: umount ...), dunno why.

[andreas]

Wild guess: if you get a "Usage:..." message it usually means that the umount parameters used in a script differ from those expected on the umount version used on the Debian image...

OR: for some reason the string of parameters doesn't get transmitted at all...

[KillaByte]

Wow - sheer awesomeness!

Dammit Toni - now I'll have to look at 68k Linux, too instead of focusing on indexing my amiga stuff

[Wepl]

Originally Posted by jotd

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.

You can use the QA-Slave from the dev package for this.
e.g. whdload qa.slave custom=83000
or better: perl qa.pl

[Toni Wilen]

Originally Posted by Wepl

You can use the QA-Slave from the dev package for this.
e.g. whdload qa.slave custom=83000
or better: perl qa.pl

What exactly should happen? I got access fault on $A0000000.

(no, I am not going to install perl. and no, this wasn't much better report either..)

[Toni Wilen]

Originally Posted by gilgamesh

EDIT: Woody starts five processesover and over again. The init and mount issues are gone here.

I can duplicate this, yay (other debian versions still have init problem here but at least I can debug this..)

[KillaByte]

OK - I've been looking into Debian a bit. I've tried images for Sarge, Etch and Sid. In all three cases I had to unpack kernel and initrd upfront.

The Sarge image is based on the 2.4 kernel. Here at least the init process is kicked off. You can drop to a shell by adding "init=/bin/sh" to the kernel command line (in the amiboot call). In the shell I can't type anything, however. The output about the umount that other users have seen occurs when the init process is trying to unmount the /proc filesystem. I've placed a call to /bin/sh in the init script right before that line to take a look around but as soon as I try to type anything in this shell I get a segfault.

The two other 2.6 based images don't even get to the point where the kernel is handing over control to the init process. The last message is that the RTC cannot be found but I don't think that this is the problem, since the RTC should be irrelevant here.

[gilgamesh]

Originally Posted by KillaByte

OK - I've been looking into Debian a bit. I've tried images for Sarge, Etch and Sid. In all three cases I had to unpack kernel and initrd upfront.

What do you mean by you "had to unpack"? Were ther errors otherwise?

Originally Posted by KillaByte

The two other 2.6 based images don't even get to the point where the kernel is handing over control to the init process.

Sarge (3.1) was the last official Debian release for m86k. Etch (4.0) has to be considered experimental. I wouldn't use that for testing in the moment.

[Toni Wilen]

winuae.zip updated again. More non-compatible MMU instructions updated (for example MOVEM to memory didn't restart correctly if any write caused access violation)

Now I only get repeating "bogl: don't know screen type 1".. (it is possible I also broke something else..)

[KillaByte]

Originally Posted by gilgamesh

What do you mean by you "had to unpack"? Were ther errors otherwise?

OK - my bad. This has to be done only for Etch and Sid. On those two it hangs while uncompressing the kernel (doesn't even get to the initrd). On Sarge it's working with the compressed images.

Originally Posted by gilgamesh

Sarge (3.1) was the last official Debian release for m86k. Etch (4.0) has to be considered experimental. I wouldn't use that for testing in the moment.

I'm well aware of that. I was just thinking I'd try the bleeding edge since Sarge didn't work too well.

Originally Posted by Toni Wilen

winuae.zip updated again. More non-compatible MMU instructions updated (for example MOVEM to memory didn't restart correctly if any write caused access violation)

Now I only get repeating "bogl: don't know screen type 1".. (it is possible I also broke something else..)

Cool - now we're getting somewhere. With the latest code the shell doesn't freeze up when trying to type something when I add "init=/bin/sh" to the kernel command line for Sarge. Without it I get an "illegal instruction" somewhere in the init script. Will have to pinpoint that tomorrow. Etch and Sid still don't make it to the initrd. If I recall correctly, you get the bogl stuff when you don't supply "debian-installer/framebuffer=false" at the kernel command line (for Sarge). Are you using the StartInstall script or do you call amiboot by hand?

EDIT:
The illegal instruction seems to happen when executing the chroot command at the end of the init script.

[Kyon]

Toni whats better with MMU support ? or what comes with MMU support ?

[Toni Wilen]

Originally Posted by KillaByte

Cool - now we're getting somewhere. With the latest code the shell doesn't freeze up when trying to type something when I add "init=/bin/sh" to the kernel command line for Sarge. Without it I get an "illegal instruction" somewhere in the init script. Will have to pinpoint that tomorrow. Etch and Sid still don't make it to the initrd. If I recall correctly, you get the bogl stuff when you don't supply "debian-installer/framebuffer=false" at the kernel command line (for Sarge). Are you using the StartInstall script or do you call amiboot by hand?

I used script that came with installation package which didn't come with that parameter. I added it, no change. Must be some bug as usual, unfortunately Linux userspace programs seems to generate huge amount of bus errors which makes finding that single non-working one very boring... (and user space MMU mapping is continuously changing which makes finding correct physical address even more annoying..)

Originally Posted by Kyon

Toni whats better with MMU support ? or what comes with MMU support ?

It is only (possibly) useful if you are programmer or want to play with Linux (or other Unix based stuff). Just ignore it. Completely.

[Kyon]

umm that means better emulation under linux with wine ?
or diffrent stuff ?

[andreas]

This "bogl" thing kept me puzzled! (Probably because I come from SUSE/Red Hat world and dunno jack shiz about Debian microcosm.) Again, Google came to my rescue: it's the acronym for "Ben's Own Graphics Library":

BOGL is a tiny graphics library for Linux kernel 2.2.x framebuffers. It's intended for use in projects that need to take up minimal space, such as rescue floppies and GUIs for PDAs.

BOGL was originally intended exclusively for Debian GNU/Linux graphical boot disks. It was also used by the NanoGUI project for a while. Currently it is in use by Debian boot disks, but not for its original purpose. I'm not the current maintainer.

If the info is still current, chances are that it WILL NOT work with the 2.4 kernel tree, let alone current 2.6. Hmm...
JFTR.

[KillaByte]

Toni, what install image are you using exactly? The bogl issue on Amiga systems is well documented for Woody and Sarge but the kernel parameters needed to avoid it change from release to release.

Originally Posted by Kyon

umm that means better emulation under linux with wine ?
or diffrent stuff ?

Nope - that means that people who want to try Linux within WinUAE will be happier. If you don't intend to run Linux or NetBSD on your emulated Amiga you don't have to bother.

[Toni Wilen]

Originally Posted by KillaByte

Toni, what install image are you using exactly? The bogl issue on Amiga systems is well documented for Woody and Sarge but the kernel parameters needed to avoid it change from release to release.

Debian Woody from http://mirrors.reflected.net/pub/deb...2-05-21/amiga/

[KillaByte]

Ah OK - will have to look into that then. I'm using the contents of this image of Sarge.

By the way - how hard do you think would it be to include support for ISO images as virtual CD drive?

EDIT:
For woody the workaround for the bogl issue seems to be adding "nolangchooser" to the kernel command line. See here

[Toni Wilen]

Originally Posted by KillaByte

Ah OK - will have to look into that then. I'm using the contents of this image of Sarge.

Ok, this shows bug when calculating start address of next instruction after write fault..

By the way - how hard do you think would it be to include support for ISO images as virtual CD drive?

Wrong topic, do not reply. (answer is: plain iso = piece of cake but i don't do it, see other cd32 related threads. anyway, this wouldn't help at all because there is no hardware level SCSI CD emulation which linux requires..)