A lot of these no longer apply to new users, but may be of interest to people who have been running Linux/m68k for a while.
This is by no means an exhaustive list. If you have any suggestions for entries, please send them to me.
There is a *wealth* of Linux documentation out there for the original PC Linux which almost always applies to Linux/m68k. Check out the documentation at your favorite Linux FTP site.
Use /dev/st0. Be aware that your tape drive must be up and
running at boot time so that Linux can recognize it and you can use
it.
It's still there, but the kernel doesn't offer it to the user. It is used by drivers that use the custom chips (like floppy, framebuffer, and sound). The z2ram driver can use this memory, but this doesn't always work right.
There is an ext2 filesystem for AmigaOS (available at http://titan.cs.bonn.edu/~fasten/). It allows you to read/write ext2 partitions. Not all write operations are currently (version 0.3) supported. Important: Make sure you read the ``Known bugs'' section.
Other ways to transfer files from Linux to AmigaOS are to use an msdos partition, an Amiga/PC formatted floppy with msdos file system (this requires a Mountlist entry on AmigaOS side), use of a partition with Minix file system and the Minix file handler on AmigaOS side (the driver is somewhat unstable) or by accessing the floppy or any (empty!) partition directly via GNU tar.
You can also read and write Amiga partitions from within Linux (using the affs filesystem). Some older install guides say that affs is read-only, but that restriction was lifted in the 2.0 series of kernels (only Directory Cache disks are read-only in 2.x).
(written by Frank Neumann)
This problem seems to be related to certain A3000 Amigas: probably only those with BootROMs. It has been discovered that if you have a DAT drive connected whose SCSI address is smaller than the smallest SCSI address of a hard disk in your Amiga, the bus will lock up very early (under AmigaOS, while the SCSI bus is being scanned: you can notice this by seeing that the SCSI LED is constantly lit and nothing happens). The solution is to use higher address for DAT drives (and maybe also for CD-ROMs) and the lower ones for direct-access media (read that as ``hard disks'').
(written by Frank Neumann)
Some devices dislike being polled on LUNs (logical units) other than
0. What can happen here is that the SCSI bus just locks up because the
device does not answer the inquiry. Quite a couple of drives have
already been added to the blacklist of ``bad'' devices in
the kernel, but there are probably more. If you discover this behavior
on one of your SCSI devices, you might try adding it to the blacklist
(in drivers/scsi/scsi.c) yourself or ask someone to do it for
you if you are sure about it.
If you think you're adventurous and want to fix the kernel for a specific SCSI device yourself, here is what you could do:
Under AmigaOS, use the scsiutil command (on Aminet) and its -i
option to send an Inquiry command to that particular device. Write
down its vendor identification, product identification and Product
revision level. For instance, an Apple CD-300 CD-ROM drive might give
(at the bottom) this output:
Vendor identification: SONY
Product identification: CD-ROM CDU-8003A
Product revision level: 1.9a
Now go into the kernel source tree and (under
drivers/scsi/scsi.c) add your drive to the blacklist of
drives that have problems (just search for
``blacklist''). Recompile the kernel and try it out without
the wd33c93= options you probably used so far.
If it works, you might want to send your change as a GNU context diff to one of the Linux/m68k maintainers.
(written by Frank Neumann)
Once in a while, it may happen to you that you try to read a binary
file. Text viewers like more will interpret the input they get as
control characters, to for instance change to an alternate character
set. This may result in a strange looking prompt, made up of special
characters. In such a case, you need to reset the terminal to its
initial state. There are several ways to do this, here's what I use:
You have to type (blindly):
echo ^V^O
Read this as: Control-V, Control-O. The sequence ``Control-O'' does just what we want: It resets the text attributes and character set, and also clears the screen. You have to mask the control character with Control-V, otherwise the shell would directly try to use the ``Control-O'' for its purposes.
Control-V Esc c is another useful sequence, which does a more complete reset of the console (but you usually won't need to use it).
You can also avoid this problem by replacing more with less.
(written by Frank Neumann and Jesper Skov)
No problem. If you moved to ELF according to Andreas Schwab's hints
(ftp://tsx-11.mit.edu/pub/linux/680x0/ELF/README), you
already have a mixed system. All old a.out shared libraries, stubs,
static libraries and simple object files (*.so, *.sa, *.o, *.a) are
now in /usr/m68k-linuxaout/lib, except for libc and libm
which remain in /lib. The ELF shared libraries are in the
usual places (/lib, /usr/lib and maybe
/usr/X11R6/lib and /usr/local/lib) and don't
interfere with the a.out libraries.
When starting a program which is either a.out or ELF, the corresponding link loader (ld.so and ld-linux.so respectively) will determine what shared libraries are required and load them on the fly. This of course works for both a.out and ELF binaries. You only have to keep in mind that with a mixed system (using some binaries which require ELF libraries while others which require a.out libraries) both ELF and a.out libraries have to be kept in memory (in particular, but not limited to, libc and libm). This certainly costs valuable memory. So, the long-term solution will be a pure ELF installation (libraries and binaries).
You can download the ELF versions of the programs via FTP, download sources and recompile, or ``Debianize'' your system (I really don't recommend the latter unless you really know what you are doing).
If you install from Watchtower-2, you will have the a.out compatibility libraries but (hopefully) no a.out binaries.
Debian/m68k will support a.out compatibility libraries, but will not include any a.out programs.
Note: Concerning a.out libraries, a couple of people had problems with the last libc that was created (4.7.2). So we recommend staying with 4.6.27 which most people were using.
Note: a.out is effectively dead on Linux/m68k. You can probably live without a.out support (you might want it available as a module, however).
Do a man patch. Understand what the -p option does. In case
the rest of the patches install ok, add a -p0 to your command
options. I usually use ``patch -s -E -p0 <
patchfile'' (s: only report errors, E: remove empty files).
If you are in the linux directory, almost all kernel patches will
apply with either -p1 (this covers all official Linux patches) or
-p0.
The older versions of the root-filesys have the wrong device numbers for
/dev/tty. Delete it and do a MAKEDEV std (you do have a somewhat current
/dev/MAKEDEV, don't you?)
The address of the ``official'' version of MAKEDEV for Linux/i386 can be found at sunsite and mirrors in http://sunsite.unc.edu/pub/Linux/system/Admin/. A list of the major/minor device numbers can also be found in the kernel tree as Documentation/devices.txt.
Debian/m68k will include a MAKEDEV that is preconfigured for Linux/m68k.
Use the file command. It will either tell you 'mc68020 demand paged' if it
is an a.out binary, and give a longer (self-explanatory) description if it
is ELF.
You can also use ldd. If it says something about a ``DLL
jump'', the binary is in a.out format; otherwise, it's in ELF.
For statically linked binaries, ldd reports statically linked
(ELF) for ELF binaries. I have no idea what it says for a.out
binaries, because I don't have anything statically linked a.out any
more (at least, not that I can find).
(written by Geert Uytterhoeven)
The current ld requires you to create links from *.so to *.so.6 for
all libs, so you should have e.g. libX11.so -> libX11.so.6,
libX11.so.6 -> libX11.so.6.0
Recent versions of ldconfig seem to take care of this
automatically.
Linux/m68k can detect the Amiga's AutoConfig devices. That it is able to detect and correctly classify these devices does not mean that the kernel has an actual driver for that device. The list of supported hardware given earlier should be exhaustive, i.e. anything that is not listed is not supported. Note: turbo boards that appear as AutoConfig devices are almost always supported (except for the SCSI controller, if they house one).
If an AutoConfig device isn't properly detected, contact Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> for details on how to make sure it will be properly detected in future kernels.
This is perfectly normal: ttyS3 and ttyS4 correspond to different physical external connectors on the Atari, but these connectors use the same internal hardware (Channel A of the SCC).
(written by Martin Apel)
What happens is that amiboot gets loaded into virtual memory and shoots itself out of accessible memory when disabling the MMU. But fortunately there's an easy way to solve this:
Enter amiboot into the task list of VMM with code and data set to "No VM". Then amiboot (version 3.0 or higher) should work correctly.
Note: Michael Schmitz has written a mini-HOWTO on this topic, which is more suited to people who are new to Linux. It is available at http://www.linux-m68k.org/ext2swap.html.
IMPORTANT: Make sure you are using e2fsprogs-1.06-swapfixed or later! The 1.05 and original 1.06 versions of e2fsprogs had serious bugs that can corrupt your disks while byte swapping.
There are three reasons why you'd want to do this:
For the purposes of this discussion, ``big-endian'' refers to the ext2 filesystem format used by default by Linux/m68k 1.2.13 (pl4-10) and ``little-endian'' or ``common'' refers to the Linux/i386 ext2fs format.
Unless you have a lot of memory, you'll need to activate some swap space before doing the byteswap (if you haven't done so already).
There are two steps. First, you must run e2fsck -f on the
partition to make sure it is completely error-free. Then use
e2fsck -s to do the byteswap to the common format. Note that
e2fsck -s will have no effect on a common format partition (so
it's OK to use it if you're not sure).
You can see whether or not a partition is in the common format by
running dumpe2fs on it. A warning message will be displayed if
it is in the big-endian format.
Recent versions of e2fsprogs (1.05 and later) will create partitions in the little-endian format by default.
Linux/m68k 2.0.29 includes a warning about big-endian format filesystems. Note that Linux/m68k 2.1.21 and later 2.1 series kernels can't mount the big-endian format (support for them has been removed). You will have to convert your filesystems before upgrading to 2.2, when it is released. (However, it is possible to convert your filesystem while running 2.1.21 or later from a ramdisk.)
It is possible that you have an IDE controller on your system without any IDE devices attached to it. If you have been experiencing problems like this, you should upgrade to kernel 2.0.28. If upgrading doesn't fix the problem, ask for help in the newsgroup.
You need modutils-2.1.23 or later. Note that these modutils are incompatible with kernels from 2.1.0 to 2.1.17, so you'll need to keep a copy of modutils-2.1.13 around if you plan on switching back and forth. The sources for modutils can be found at ftp://ftp.redhat.com/pub/alphabits/ or a more reliable mirror, ftp://tsx-11.mit.edu/pub/linux/projects/alphabits/.
If you're running 2.1.26 or later, no patches should be necessary (beyond the ones you had to apply to get that version to compile).
Modules in 2.1 series kernels also require running libc 5.4.17 or later (which in turn requires ld.so 1.8.5 or later).
(S.u.S.E. info written by Christian Steigies)
In the United States and Canada, at least two distributors currently offer Linux/m68k archives (as part of the tsx-11 mirror) on CD:
ftp.uni-erlangen.de from October 1996.
At one time, Linux/m68k was included as part of Infomagic's Linux Developer's Resource; all non-Intel support was dropped with the December 1996 set. Supposedly they plan to issue a separate Ports CD-ROM (in ``late December'' of 1996 [not a misprint]).
In Europe, S.u.S.E. distributes a 4 CD set called ``S.u.S.E.
aktuell!''. The latest edition is from March 1997. In addition to a
direct mirror of erlangen's 680x0 tree, a mirror of
ftp.phil.uni-sb.de's linux-m68k tree is included (as of 20
February 1997). Each set is 45 DM (about $27 US), or you can
get a 6-set subscription for 209 DM in Germany and 259 DM (about
$155 US) outside of Germany. S.u.S.E.'s web site is at
http://www.suse.de/ (if you can grok German). S.u.S.E. will be
releasing a similar product in the United States in the near future
(see
http://www.suse.com/ for details).
Christian Steigies reports:
I've just bought the new CD set from SuSE (Linux aktuell! March 1997).
You probably want to update it in the FAQ. BTW "Ausland" means foreign
countries, so your german is in fact quite good :-) I don't know if
you want to include this in the FAQ or if you shorten it a bit, but
I'll give you some comments about it anyway.
The snapshots were made on Feb 20, 1997 (although the README says
1996, don't trust the README, the LIESMICH (german) seems to be more
trustworthy). On CD 2, the two 68K servers are mirrored, Saarbruecken
and Erlangen.
In fact CD 2 is the best of all the four, not only because the 68K
mirrors are there, but also because of the .au files telling you how
to pronounce "Linux" correctly (/cdrom/kernel/SillySounds/*.au ;-)
Some things were left out in the snapshots, from the 68k stuff this is:
- Files more than 1 1/2 years old
- the phil-sb mailinglist (lack of space)
- and, unfortunately, filesys-ELF-2.0.x-1400-2.gz and filesys-ELF-2.0.x.gz
because of damaged archives. These two are included on the Dec CD, I don't
know why they should be damaged right now (I'll try to ask them)
Everything else to set up m68k Linux and more should be there:
- watchtower filesys
- amiboot up to 5.4
- ataboot up to 2.2
- m68KLinux FAQ 2.0.11 (from Feb 13, 1997)
- kernel + sources up to 2.0.28/2.1.26 (missed 2.0.29 only by a few days...)
- binutils-2.7.0.3.chip-fixed-tesche (no longer available from erlangen,
then new binutils-2.7.0.9 doesn't work for me...)
- gcc-2.7.2.2
- libc up to 5.4.17
- XFree68-3.2 and 3.2A
- lots of other stuff
So get CD 2 plus filesys-ELF-2.0.x-1400-2.gz via ftp or from the Dec
CD and you got all to set up m68k Linux. Talk the CD 2 away from an
Intel freak, it's not much use for him anyway ;-)
If you have already started using the Debian packaging system,
iConnect Corporation distributes CDs of master.debian.org which
are updated every 2-3 days and should include the unstable/binary-m68k
tree. 1.3 (bo/fixed) snapshot CD's are $25 US (plus $5
US shipping and handling inside the US and $10 US elsewhere).
Pre-2.0 (hamm) snapshots should be available soon. Check out
http://www.i-connect.net/ for details.
Once you have a copy of the Linux/m68k kernel, you should rarely need to get a completely new tree. Instead, you can patch the kernel sources to the next released version.
For example, if you have the 2.0.25 kernel tree already, you need to
get the file linux-2.0.28.diff.gz via FTP (don't get the file
with the word ``native'' in it unless you have the same
version kernel tree for Linux/i386). Then use cd to get to the
directory above your kernel tree (probably /usr/src), and
make a copy using hard links to save a lot of space:
cp -rl linux-2.0.25 linux-2.0.28
You may also want to change your symbolic link linux ->
linux-2.0.25 to point to the new tree:
ln -sf linux-2.0.28 linux
This way, your links in /usr/include don't have to be changed
every time you upgrade your kernel (i.e. you can link
/usr/include/linux -> /usr/src/linux/include/linux instead
of using the kernel version number hard-coded). Then, cd to
linux-2.0.28 and type the following 2 commands:
rm -rf include/asm
zcat (path of linux-2.0.28.diff.gz) | patch -p1 -s
If all goes well, it will work for a minute or two and then return you
to your shell's prompt. Make sure the patch applied correctly by
typing find . -name '*.rej'. If no filenames are listed,
everything worked perfectly.
Now do a make clean to delete all the backup .orig files
left by patch, and then do a normal make config, make dep
and finally make.
Once you've successfully made a copy of the new kernel, you can
safely delete the previous version's tree using rm -r.
Miniproject: Someone with a bit of spare time might want to adapt
scripts/patch-kernel to understand Linux/m68k diffs.
Please note that you will get rejected patches if you patch a kernel tree that you patched from the Linux/m68k mailing list (or from any other source). The easiest way to avoid this is to make a ``clean'' (i.e. distribution) kernel tree and another tree which you apply the patches from the mailing list to.
Recent models of the Jaz drive (with firmware version H.71 and later) are shipped in a so-called ``write-verify'' mode. This mode causes problems for operating systems (like Linux) that can't run Iomega's proprietary drivers.
I (Chris) have been in touch with Iomega tech support, and they provided me with the low-level commands that allegedly get the Jaz drive into the correct mode. However, the commands they provided don't seem to work (probably (ab)user error, knowing my level of SCSI programming knowledge).
In the meantime, the only thing to do is find a Mac or PC with a SCSI interface and use Iomega's Jaz Tools software to disable the write verify mode. This can also be done with a registered copy of Shapeshifter on the Amiga. On a PC, you will need to use the Windows version of Jaz Tools to disable write-verify (the DOS version of the tools won't do it).
More information about the Jaz drive and Linux (including the Jaz mini-HOWTO) can be found at Bob Willmot's Jaz-Linux information page.
This usually means that you are running a buggy version of getty.
The agetty and mingetty versions of getty are known not
to have this problem, so replace your current getty with one of
these. The getty version included in Debian/m68k will also work
correctly.
[It may not actually be a bug in getty. But replacing it seems to fix the problem.]
Older kernels with FPU emulation are available from ftp://ftp.nocrew.pp.se/pub/linux/. The FPU emulation code used is adapted from NetBSD, and has bugs originating from both the emulation code itself and the Linux interface to it. The emulation code does not support all transcendent functions and not all supported functions have full precision implemented. Use of this FPU emulation code is not supported, endorsed, or sanctioned by the kernel developers; please do not send them bug reports, complaints, or even patches to this code.
The reason why the old FPU emulation code is unsupported is that its license is incompatible with the GNU General Public License. The code is restricted under the terms of the Berkeley Source Distribution license, which requires that accompanying code and documentation recognize the contributions of the University of California to the software. While this may seem to be a trivial point, the GPL does not allow any restrictions beyond those in the GPL on how software linked to the GPL can be distributed.
A new effort to write an improved FPU emulator under a GPL-friendly license is in the works; it is planned that this emulator will be licensed so it can be used without any strings attached (probably under something like the MIT X license). If you are interested in helping with the coding (no testing yet), join the discussion on the Linux/m68k mailing list. When the FPU emulator is ready for testing, announcements will be made on the mailing list and in the newsgroups.
This is usually because of the initrd driver. Make sure you specify
on the boot line ``-r <ramdisk-name> root=/dev/ram''.
The other possibility is that you don't have enough RAM to boot from a RAM disk (you really need at least 6 MBs with recent kernels). In this case, it is possible to write the ramdisk's contents to a high density disk and try booting from this (but you do need a HD disk drive to do this). Ask in the newsgroup for help if you don't know how to do this on your own. Alternatively you may be able to get someone else to compile a smaller kernel image specifically for your system (which will save a lot of RAM).
As a security precaution, most systems come preconfigured to not
include the current directory in your path. The lazy way out is to
add '.' to your path, but I strongly recommend against doing that
(particularly if you are running as root).
The right way to handle this situation is to preface the program name with ``./''. For example, type ``./configure'' instead of ``configure''.
This is done with the ``video'' boot parameter. For details on what
resolutions are supported, you'll want to read
Documentation/m68k/framebuffer.txt and
Documentation/m68k/kernel-options.txt in the Linux/m68k
kernel source tree (the former document only appeared in 2.0.28).
You can also specify what font you want to use with the font
option to 'video'.
For example, to boot into 640x480x4 mode on an Amiga with a 31 kHz or
multiscan monitor, use video=vga.
I use video=font:PEARL8x8,vga on my Amiga 4000, for a very nice
80x60 text display.
The easiest way to fix this is to change the ``Modes'' line
in your /etc/XF86Config to read:
Modes "default"
Later on, you can get Geert Uytterhoeven's fbset program from
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/ and
customize your video modes.
If you have an old XF86Config laying around, you may want to copy the
example provided at /usr/X11R6/lib/X11/XF86Config.eg into
/etc/XF86Config and then edit the new configuration file.
(written by Geert Uytterhoeven)
If you have a PAL-based Amiga with a true Multisync monitor (like the A1960), try these as starters (they should be typed on one line):
ModeLine "vga70" 28.376 640 736 848 912 400 412 414 449 +VSync +CSync ModeLine "vga" 28.376 640 736 848 912 480 489 491 521 ModeLine "832x624" 28.376 832 940 1020 1024 624 628 630 660 Interlace +HSync +VSync ModeLine "832x600" 28.376 832 964 1044 1096 600 600 602 636 Interlace +HSync -VSync ModeLine "896x672" 28.376 896 1044 1108 1160 672 676 678 708 Interlace -HSync +VSync -CSync ModeLine "960x720" 28.376 960 1132 1172 1224 720 720 722 754 Interlace -HSync -VSync -CSync ModeLine "1024x768" 28.376 1024 1196 1212 1288 768 772 774 804 Interlace -HSync +VSync -CSync
For NTSC, you can try replacing 28.376 with 28.636 (but this hasn't been tested). Note that each ModeLine should be entered on one line in your XF86Config file.
(written by Geert Uytterhoeven)
You can create the frame buffer special device nodes for the Amiga using the following commands:
mknod /dev/fb0current c 29 0
mknod /dev/fb0autodetect c 29 1
mknod /dev/fb0ntsc c 29 2
mknod /dev/fb0ntsc-lace c 29 3
mknod /dev/fb0pal c 29 4
mknod /dev/fb0pal-lace c 29 5
mknod /dev/fb0multiscan c 29 6
mknod /dev/fb0multiscan-lace c 29 7
mknod /dev/fb0a2024-10 c 29 8
mknod /dev/fb0a2024-15 c 29 9
mknod /dev/fb0euro36 c 29 0
mknod /dev/fb0euro36-lace c 29 11
mknod /dev/fb0euro72 c 29 12
mknod /dev/fb0euro72-lace c 29 13
mknod /dev/fb0super72 c 29 14
mknod /dev/fb0super72-lace c 29 15
mknod /dev/fb0dblntsc c 29 16
mknod /dev/fb0dblntsc-ff c 29 17
mknod /dev/fb0dblntsc-lace c 29 18
mknod /dev/fb0dblpal c 29 19
mknod /dev/fb0dblpal-ff c 29 20
mknod /dev/fb0dblpal-lace c 29 21
mknod /dev/fb0vga c 29 22
mknod /dev/fb0vga70 c 29 23
mknod /dev/fb0user0 c 29 24
mknod /dev/fb0user1 c 29 25
mknod /dev/fb0user2 c 29 26
mknod /dev/fb0user3 c 29 27
mknod /dev/fb0user4 c 29 28
mknod /dev/fb0user5 c 29 29
mknod /dev/fb0user6 c 29 30
mknod /dev/fb0user7 c 29 31
(written by Haidinger Walter)
Before trying to run X, you should edit /etc/XF86Config. Look
for the Monitor section. Set the ``HorizSync'' and
``VertRefresh'' values to the specifications matching your monitor.
That is, e.g. for the M1438S *only* :
HorizSync 15-40
VertRefresh 45-90
Do a ``man XF86Config'' for a detailed description.
Of course, this provides neither a warranty nor an insurance that you cannot damage your monitor, but it will be much more difficult now...
(Maintainer's note: I fried my monitor once by blindly copying someone's HorizSync and VertRefresh values. Make certain that you are using the correct values for YOUR monitor; they should be in the book that came with it. And if your monitor starts acting funny, switch it off immediately!: if I had switched mine off, I could have saved myself a $100 US repair bill.)
There is a minor bug in the 2.0.28 transparent translation code that breaks framebuffer access for all applications (not just X, but there really aren't many others :-). You should be able to obtain a patch for this bug at James Troup's Linux/m68k pages.
Alternatively, upgrade to 2.0.29, which fixes this bug and several others.
There is a minor bug in the released 2.0.33 source tree that breaks framebuffer access. There is a patch at James Troup's Linux/m68k pages.
This is usually because Jes doesn't have the time to test every single configuration before releasing the kernel sources. Monitor the Linux/m68k mailing list for patches (usually all the fixes have been posted after about two days).
In addition, James Troup maintains a set of pages with the latest patches and release announcements at http://thor.lib.chalmers.se/linuxm68k/.
(written by Geert Uytterhoeven)
This bug apparently appeared in kernel 2.1.15. Geert says:
Gadi Oxman (the IDE guru) told me this could be due to buggy IDE interfaces, IDE drives or both (or a bug in the driver, of course :-), and he suggested to try ``ide0=noautotune'' which solved my problem last Thursday. But I can't be 100% sure this really solved it...
(written by Geert Uytterhoeven)
To compile these programs, you'll need the Amiga Developer's
Environment (the GNU tools for creating AmigaOS programs). Linux/m68k
binaries of ADE are available at
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/devel/ADE.tar.gz.
You will also want the ADE.readme file from the same location.
(written by Christian Steigies)
You will need the ``loadkeys'' command, it is part of the kbd package.
kbd is maintained by Andries E. Brouwer <aeb@cwi.nl> and you can find it at
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/ and
ftp://ftp.win.tue.nl/pub/linux/util/. The current version is
0.93.
On the SuSE aktuell (March 1997) an older version is on CD 2 as
/kernel/kbd-0.92.tar.gz
Install kbd (gunzip and untar the archive, preferably in
/usr/local/src, then ``make'') and ``make install''. If you use
version 0.92 (or lower?) you need to remove resizeicons from the
Makefile). You will then have all the executables in the right place
and a whole lot of keymaps in /usr/lib/kbd/keytables/
As of version 0.93 these keytables are more or less useless for m68k users, since they are for PC-style keyboards. Loading one of these on an Amiga or Atari screws up the keyboard layout so that its virtually unusable.
You need to make one by yourself or get one from
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/,
where Roman Hodek has started collecting Amiga and Atari keymaps. Get
the keymap you want to install, say de-amiga.map, and put it in
/usr/lib/kbd/keytables/ (In newer kbd versions, hopefully
m68k keymaps will also be included.)
Typing ``loadkeys de-amiga'' will then load this keymap.
To load this keymap during boot, create a rc.loadkeys in /etc/rc.d
like (don't include the lines starting with ---):
--- rc.loadkeys ---
#! /bin/sh
#
# rc.loadkeys load german keyboard map
#
# Version: @(#)/etc/rc.d/rc.loadkeys
#
loadkeys de-amiga
--- rc.loadkeys ---
Debian/m68k has a more automated way of handling the keymaps (through
the kbd Debian package). The package includes several Amiga and
Atari keymaps.
(written by Christian Steigies)
The ``showkey'' command (part of kbd) will tell you which scancode is generated for every key you press, just write down what you want to be generated by this key ;-)
The easiest way is to get a keymap for your computer and only change the keys you want to be mapped differently. ``dumpkeys'' shows you the current keyboard mapping, ``dumpkeys -l'' will show you all the names of the symbols which can be mapped to the keyboard. ``man keytables'' tells more about creating keytables.
When you have made a keymap, contact Roman Hodek <rnhodek@informatik.uni-erlangen.de> so you can upload it.
(written by Christian Steigies and Haidinger Walter)
To type umlauts and more in bash, create an .inputrc in your home
dir with:
--- .inputrc ---
set meta-flag On
set convert-meta Off
set output-meta On
--- .inputrc ---
Within tcsh, you need to use the following procedure:
You need an 8-bit clean tcsh with nls support along with the locale package.
In your tcsh, type ``echo $version''. It should say something like
tcsh 6.07.02 (Astron) 1996-10-27 (m68k-unknown-linux) options
8b,nls,dl,= al
Only the options are important. It should show at least ``8b'' and ``nls''. If not, you need to recompile tcsh, but, AFAIK, the tcsh binary on the Linux/m68k mirrors has both options set.
(written by Haidinger Walter)
To use locale, you need at least libc-5.4.17. I'd recommend to install the lib/libc-5.4.23.bin.tar.gz package if you haven't already. 5.4.23 is a bug-fix release to 5.4.17 and does not introduce new features.
Next, you need the locale database. I know two sources:
suse/a1/localedb.tgz
(usually on CD1) to /
lib/glibc-2.0.2-m68k-linux.bin.tar.gz from
the Linux/m68k mirror also contains a _partial_ locale database. To
unpack just the database, type on one line:
tar -zxvf glibc-2.0.2-m68k-linux.bin.tar.gz
"usr/share/locale/*" "usr/share/i18n/*"
Whether you have the SuSE distribution or not, I strongly recommend that you read the mini-Howto 'Locales' at least once. It not only describes how to get, build and install the locale package, but also the system requirements and, most important, the usage of the associated commands and environment variables!
So, just follow the instructions of the 'Locales' mini-HOWTO to setup the locale-package and customize it to your system. Finally, set your enviroment variables to the approprite values and put them into your .tcshrc.
If you cannot wait that long, have a look at
/usr/share/i18n/locales. If you're German, try (in tcsh):
setenv LC_ALL de_DE
setenv LC_LANG de_DE
bash users would use:
LC_ALL=de_DE
LC_LANG=de_DE
export LC_ALL LC_LANG
(written by Haidinger Walter)
After installing glibc, run ldconfig. Then type ls -l /usr/lib/libc.so. Is it a symlink to libc.so.6 ? Well, this is not correct for glibc.
Type:
rm /usr/lib/libc.so
echo "GROUP ( libc.so.6 ld.so.1 libc.a )" > /usr/lib/libc.so
Note that if you run ldconfig now, it may issue a warning about libc.so not being a shared libary. That is ok, ignore the warning.
(written by Haidinger Walter)
You are missing the /etc/psdevtab file. Type ``touch /etc/psdevtab'' (as root) and run ps again.
(written by Haidinger Walter)
It says something about an old/bad ncurses library/header but I have the latest lib/ncurses-1.9.9e.bin.tar.gz from the Linux/m68k mirror!
Get the source of ncurses-4.1.tar.gz. It can be found at ftp://ftp.fu-berlin.de/pub/unix/gnu/. Compile it. You should not have any troubles following the descriptions in the INSTALL file. Be sure to install the include header-files too.
Next, you can type ``ln -sf /usr/include /usr/include/ncurses'' since some packages look for the ncurses headers in ``/usr/include'' while others look in ``/usr/include/ncurses''.
(written by Haidinger Walter)
By mounting. First you need a mount-point, i.e. a directory under which you can access your floppy. You can chose an arbitary name, I use /df0 through /df3 (and /pc0 to /pc3 respectively) because I'm used to these names from AmigaOS.
Create the directores. e.g.:
mkdir /df0
mkdir /any-name-will-do
mkdir /ados/df0
mkdir /ados/pc0
...
Next, check if you have the proper device nodes: Type:
ls -l /dev | grep "^b.* 2, [0-7]"
For me, that lists:
brw-r--r-- 1 root wheel 2, 0 Mar 31 18:16 df0
brw-r--r-- 1 root wheel 2, 1 Mar 31 18:16 df1
brw-r--r-- 1 root wheel 2, 2 Mar 31 18:16 df2
brw-r--r-- 1 root wheel 2, 3 Mar 31 18:16 df3
brw-r----- 1 root 25 2, 0 Jun 22 1996 fd0-
brw-r----- 1 root 25 2, 4 Feb 26 1994 fd0d360
brw-r----- 1 root 25 2, 4 Jun 22 1996 fd0d360-
brw-r----- 1 root 25 2, 5 Jun 22 1996 fd1d360
brw-r--r-- 1 root wheel 2, 4 Apr 4 11:49 mfd0
brw-r--r-- 1 root wheel 2, 5 Apr 4 11:49 mfd1
brw-r--r-- 1 root wheel 2, 6 Apr 4 11:49 mfd2
brw-r--r-- 1 root wheel 2, 7 Apr 4 11:49 mfd3
brw-r--r-- 1 root wheel 2, 4 Mar 31 18:03 pc0
brw-r--r-- 1 root wheel 2, 5 Mar 31 18:16 pc1
brw-r--r-- 1 root wheel 2, 6 Apr 8 12:03 pc2
brw-r--r-- 1 root wheel 2, 7 Apr 8 12:03 pc3
^ ^ ^ =09 ^^^
block-device major minor node-name=20
Do not worry if you have other results. What do you need to know?
0 to 3 ... Amiga drives 0 to 3 (i.e. df0 to df3)
4 to 7 ... MS-DOS drives 0 to 3 (i.e. pc0 to pc3)
Now create the device-nodes:
mknod /dev/df0 b 2 0
mknod /dev/df1 b 2 1
mknod /dev/df2 b 2 2
mknod /dev/df3 b 2 3
mknod /dev/pc0 b 2 4
mknod /dev/pc1 b 2 5
mknod /dev/pc2 b 2 6
mknod /dev/pc3 b 2 7
Set the desired permissions with the chmod command.
Remember, the names (here: df0 and pc0) are arbitary. However, on Intel Linux systems, the floppy nodes are named /dev/fd* To access devices under different node-names, just create symlinks. e.g:
ln -sf /dev/pc0 /dev/fd0
ln -sf /dev/pc1 /dev/fd1
ln -sf /dev/pc2 /dev/fd2
ln -sf /dev/pc3 /dev/fd3
Now, MS-DOS drive 0 can be accessed by /dev/fd0 as well as /dev/pc0. If you want /dev/fd0 to be an Amiga drive, link it to /dev/df0 instead. Of course, this are just examples from my configuration. You can choose other names if you like.
After having mount-point and device-node, you can mount your floppy.
For an AmigaOS disk in drive 0:
mount -t affs /dev/df0 /df0
ls /df0
...
umount /df0
For a MS-DOS disk in drive 1:
mount -t msdos /dev/pc1 /pc1
ls /pc0
...
umount /pc0
Warnings:
You can also put this into your /etc/fstab file. Mine looks like this:
# device mountpoint type options freq passno
# --------------------------------------------------------------------------
# Amiga Floppies
/dev/df0 /ados/df0 affs defaults,noauto,noexec 0 2
/dev/df1 /ados/df1 affs defaults,noauto,noexec 0 2
/dev/df2 /ados/df2 affs defaults,noauto,noexec 0 2
/dev/df3 /ados/df3 affs defaults,noauto,noexec 0 2
#
# MS-DOS Floppies
/dev/pc0 /ados/pc0 msdos defaults,noauto,noexec 0 2
/dev/pc1 /ados/pc1 msdos defaults,noauto,noexec 0 2
/dev/pc2 /ados/pc2 msdos defaults,noauto,noexec 0 2
/dev/pc3 /ados/pc3 msdos defaults,noauto,noexec 0 2
I'm not quite sure about the freq/passno fields. Do a 'man 5 fstab' and a 'man 8 mount' for more info.
Other topics about floppies:
You can use the 'mtools' package to access MS-DOS disks without the
need of mount/umount. The mtools-3.6.tar.gz package compiled
without any problems out of the box for me. The nodes /dev/fd0 and
/dev/fd1 are used to access the MS-DOS drives. If you followed my
descriptions above it is not necessary to edit mtools.conf (in /etc or
/usr/local/etc)
I do not know if mtools can be configured to work with Amiga disks too. If it can be done, please let me know!
Hhm. Good question. There are some binaries in
bin/system/floppy at
ftp.uni-erlangen.de. Unfortunately for me, fdformat
dies with a segmentation fault and amifdformat-formatted
disks can't be mounted using affs. Any suggestions are
welcome!
(written by Haidinger Walter)
Do a 'man 8 mount' and search for a section entitled ``THE LOOP DEVICE''.
Create the device-nodes if they do not exist yet:
mknod /dev/loop0 b 7 0
mknod /dev/loop0 b 7 1
...
mknod /dev/loop9 b 7 9
More information and examples can be found in:
Note: To use loop devices, you must have a kernel which supports them.
(written by Haidinger Walter)
Assuming that you have read 'Documentation/modules.txt' in the kernel sources and you have already installed the correct version of modutils, you should type ``modprobe -c | grep -w major-2''
You should get:
alias block-major-2 amiflop
If it shows 'floppy' instead of 'amiflop', then the kernel searches
for a module named 'floppy', which does not exist for Linux/m68k. You
have to add the above line to your /etc/conf.modules to
assign the proper name. This is also true for some other modules. See
the next question for details.
Note: Atari users will want to replace 'amiflop' with 'ataflop'.
The kernel looks for the modules under /lib/modules/. The
modules are referenced by name. However, some of the m68k-specific
modules have different names from their Intel counterparts. Here is an
(uncomplete) list:
# file /etc/conf.modiles
alias eth0 ariadne # depends on your Ethernet card (or off)
alias block-major-2 amiflop
alias char-major-4 amiga_ser
alias char-major-6 lp_intern
alias char-major-14 dmasound
alias net-pf-3 off # no ax25 module available (yet)
alias net-pf-4 off # if you don't use the ipx module
alias net-pf-5 off # if you don't use the appletalk module
If you have any alias that are missing here, please mail!
Some of these settings may be done automatically by recent versions of
modutils.
If BrandX is the Amiga or Atari, it's because for the most part we've found that once you get past installation, running Linux on both systems is pretty much the same. There are a few machine-dependencies that affect day-to-day use (port assignments and keymaps, for example), but 99% of the time it makes no practical difference what system you run Linux on.
The configuration is fairly easy. Tell the application you are using a bus mouse, and make a soft link from /dev/amigamouse (for Amigas) or /dev/atarimouse (for Ataris) to /dev/mouse.
You may also want to enable 3-button emulation if you only have a two-button mouse.
(written by Roman Hodek, Petr Stehlik and Thomas Kruse)
Roman says:
On a Falcon with Afterburner040, the bootstrap can be run only on a fully initialized machine, i.e. the AB040 software drivers must be loaded. More specifically, bootstrap relies on the _CPU cookie to be set to 68040, which is done by that driver. But there may be also other dependencies...
Additionally, the bootstrap must have its program flags set to ``don't run in TT-RAM'' and ``don't allocate memory from TT-RAM''. This is due to the fact that TT-RAM on the AB040 is mapped by the MMU and addresses in it can become invalid as soon as the MMU is switched off before launching Linux. Bootstrap issues an error messsage if either its code or data reside in TT-RAM, so you can't make it wrong, but maybe you don't know how to fix it... :-)
And finally: Currently the Linux kernel won't run properly in TT-RAM. Better use the -s flag to bootstrap (``load kernel to ST-RAM''). We're working on the problem, but a solution isn't evident yet...
Petr provides the following advice:
The Afterburner040 is a card with 68040 CPU and two FastRAM slots for the Atari Falcon 030. There are several different revisions of that card which also affect Linux. General rules for successful Linux boot are as follows:
ataboot) version 3.1 or higher (older
versions of ataboot didn't recognize FastRAM properly)
Thomas Kruse says that ``not only must the read modify write optimization be turned off, the whole 68040 specific optimizations must be turned off - otherwise the kernel won't run reliably on different circumstances and sizes of the kernel.''
The discussion on the mailing list seems to indicate that there isn't a specific approach that seems to work well for everyone. Hopefully this situation will be resolved soon.
(written by Roman Hodek)
For users of the PAK030 board for STs, burst mode for memory is better disabled when running Linux. With burst mode enabled, several users experienced spurious memory corruption problems.
You will need a program that can extract gzip-compressed tar archives for your system. Mac users can use recent versions of StuffIt Expander; Windows users can use recent versions of WinZip. There is a program called ``Opener'' for NeXTs that will also work.
Alternatively, you can obtain the GNU gzip and tar programs for your current OS. On Aminet (for Amiga users), you should be able to find these in devel/ade, util/gnu or util/arc. Older copies of these tools are in the ``tools'' directory at Erlangen and its mirrors.
There is a French translation of this FAQ available at http://web.cnam.fr/Comp/Atari/Linux68k/Faq/, translated by Christian Jacolot. However, this URL seems to have died over the Christmas holidays (does anyone know where I can find a copy?).
If you're interested in translating the FAQ into another language, please let me know and I'll try to point you in the right direction.
The current affs driver doesn't support Unix-style devices on
Amiga partitions, which makes it impossible to use an Amiga partition
as root. A future release may support an emulation of devices and
other Unix special files, perhaps based on the umsdos
filesystem available.
You can use affs disks as secondary partitions. The AmigaOS 2.0+ symbolic and hard links are used to emulate the similar Unix features (hard links work as expected; soft links outside of the same directory will not work as expected from both sides).