Note: The available minors depend on the kernel version you are using; this discussion pertains to the driver as included the 2.2 kernel series (the 2.0 kernel series does not support the "memory list" options). As of 2.2.1, z2ram has the same capabilities on both Linux/m68k and Linux/APUS.
Basically, the z2ram device driver allows you to use memory that is not being used by Linux/m68k as swap space or a ramdisk (you could use it for a /tmp partition, for example). While the name implies the device only is useful if you have "Zorro II" memory, it actually permits the use of any chip or fast memory on your system that is not already being used by Linux/m68k.
The z2ram driver is enabled using the "Amiga Zorro II ramdisk support" option during kernel configuration. It may already be a module in your default kernel setup.
It is a block device (major 37); you can have a number of different z2ram devices operating at once. Each minor number provides access to different areas of memory:
Minor 0: Use available chip and Zorro II fast memory
Minor 1: Use only Zorro II-addressable fast memory
Minor 2: Use only chip memory
Minor 3: (unused)
Minors 4-7: Use memory list entry 1-4 (see below)
Minor 1 is most useful if you have Zorro II memory on your system (perhaps on a SCSI controller card) that is slower than the memory on your motherboard or accelerator card, but is still faster than a hard disk. These memory areas are automatically excluded from your system memory during the boot process. Note that you may have Zorro II memory even if you don't have a Zorro bus on your computer (for example, if you have an A500 or A1000 expansion box; PCMCIA memory cards may also be seen as Zorro II memory on the A600 and A1200).
Minors 0 and 2 provide access to chip memory. While this can be useful at times (and chip memory is generally faster than Zorro II memory on the A3000 and A4000), parts of the kernel that expect to be able to get extra chip memory on demand may cause problems. The amifb framebuffer device is one example of a device that may need chip memory "on the fly" (for example, if you increase the depth or size of a framebuffer); amifb may react very poorly to running out of memory it expects to be able to find. If you are using another framebuffer instead of amifb, chip memory access through the z2ram device may be less problematic.
Minor 3 isn't used by anything at the moment.
Minors 4 through 7 were developed for Linux/APUS, but can also be useful under Linux/m68k on Amigas with more than one memory area where the access times to the different types of memory significantly differ (i.e. an Amiga with an accelerator card that has on-board SIMM sockets and other memory on the motherboard or expansion bus). In these situations, you can use the z2ram device in conjunction with the Linux paging code to help ensure that slower memory is only used when the faster memory blocks are completely full. To take advantage of this capability, you should configure your kernel to "Use one physical chunk of memory only" (under the "Advanced options" section after you select the CPU you want to use).
Once you have recompiled your kernel this way, you should make sure the memory block with the best access to your CPU is being used as your main system memory (usually this will be the memory on your accelerator card or on the motherboard), i.e. is listed first when amiboot lists the chunks of memory that have been found. You may need to make a "memory list" for amiboot if the AmigaOS memory priorities are not ordered sensibly. In any event, amiboot will list the chunks of memory it decides are available in the order they should be used; the first chunk listed will be used as your main system memory.
The remaining chunks (actually, the second through fifth chunks... if you have more than five memory chunks, you can hack the driver to permit more) can be used by the z2ram driver using the above-listed minor numbers. So the second chunk on the list will be minor 4, the third chunk will be minor 5, etc.
You have two options: you can use each z2ram area as either swap space or a partition (but not both at the same time for a particular instance... although you could put a swap file on a z2ram partition). Basically all you have to do is enable the z2ram driver in your kernel and create the block special files you need in /dev; then you can treat each z2ram area like any other block device (such as a floppy or hard disk drive).
Note that if you have multiple blocks of memory, you can use some blocks as swap and others as partitions; you just can't use the same memory block for both purposes at once.
Specific instructions for both uses follow:
Make a block special file for the device. This is done with the mknod command. For example, to make a device called "/dev/fastram" that uses your Zorro II memory, use mknod --mode=600 /dev/fastram b 37 1. Here 1 is the minor number used for Zorro II memory (see above), it could also be 0, 2, 4, 5, 6 or 7, as appropriate.
Prepare the swap space for use. Following the example above, mkswap /dev/fastram.
Make the swap space available to the system. For this, use the "swapon" command: swapon -p 1 /dev/fastram. The -p 1 parameter tells the kernel to put this swap space in at a higher priority (1) than the default (a negative number, which depends on how any swap spaces are already enabled), so it will be used before your hard disk.
To make this change permanent, you will need to edit your system startup files to prepare and enable the swap space on each boot by adding the "mkswap" and "swapon" lines to one of your early startup scripts (on Debian, you should add a small script to /etc/rcS.d around priority S04: see the Debian init information for more details). Here's a simple init script that will handle this procedure during each boot:
mkswap /dev/fastram swapon -p 1 /dev/fastram |
If you are using z2ram as a module, you may need to make sure the module dependencies are available when the script runs so kmod (assuming you use it) can automatically load the driver.
The principles involved in the ramdisk are similar to those for a swap partition:
Make a "block special file" for the device. This is done with the mknod command. For example, to make a device called "/dev/mbram" that uses your motherboard memory (which, I assume for the purposes of this example, is the second entry on your memory list), use mknod --mode=600 /dev/mbram b 37 4. Here 4 is the minor number used for the second memory list entry (see above), it could also be 0, 1, 2, 5, 6 or 7, as appropriate.
Prepare the ramdisk for use: mke2fs /dev/mbram will do the job nicely (you could also use another filesystem format if you like, but ext2 is probably the best for most uses).
Make the ramdisk available to the system. For this, just mount it somewhere; e.g. mount -t ext2 /dev/mbram /mnt. The -t ext2 tells mount that you have an ext2fs filesystem, and should be changed if you use some other filesystem like Minix.
To set up a /tmp ramdisk for each boot, you should edit your startup scripts to format the ramdisk (since, for obvious reasons, the ramdisk doesn't stay formatted over reboots) and mount it. You may also need to set the permissions for the tmp directory properly on each boot. Here's a sample script that takes care of things:
mke2fs -q /dev/mbram mount -t ext2 /dev/mbram /tmp chown root.root /tmp chmod 1777 /tmp |
On a Debian system, this should be dumped into an rcS.d file; see the Debian policy manual for an explanation of the Debian init file scheme. The note under the swap space section about z2ram as a module may also apply.