ANews 2

home *** CD-ROM | disk | FTP | other *** search

/ ANews 2 / AnewsCD2.iso / LinuxPPC / Amiga / faq / faq.sgml < prev next >

Wrap

SGML Document | 1999-10-08 | 182.6 KB | 5,257 lines

<!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [  <!ENTITY thisdoc "The &linapus; Doc'n'FAQ"> <!ENTITY linux "Linux"> <!ENTITY linapus "Linux/APUS"> <!ENTITY linm68k "Linux/m68k"> <!ENTITY linppc "Linux/PPC"> <!ENTITY cpuppc "PowerPC"> <!ENTITY cpum68k "MC68k"> <!ENTITY cpu040 "MC68040"> <!ENTITY cpu060 "MC68060"> <!ENTITY cpu603 "PPC603p"> <!ENTITY cpu604 "PPC604"> <!ENTITY sunsite "SunSITE Denmark"> <!ENTITY gvp "GVP"> <!ENTITY p5 "Phase5"> <!ENTITY pup "PowerUp"> <!ENTITY blzppc "Blizzard/PPC"> <!ENTITY cybppc "CyberStorm/PPC"> <!ENTITY gdb "<application>GDB</application>"> <!ENTITY x "<application>X</application>"> <!ENTITY dmesg "<application>dmesg</application>"> <!ENTITY boothack "<application>boothack</application>"> <!ENTITY amiboot "<application>amiboot</application>"> <!ENTITY rh "RedHat"> <!ENTITY rpm "RPM"> <!ENTITY rhinstaller "RedHat Installer"> <!ENTITY rhppc "RedHat/PPC"> <!ENTITY rhrc "RedHat/Rough Cuts"> <!ENTITY debian "Debian"> <!ENTITY debppc "Debian/PPC"> <!ENTITY deb "DEB"> <!ENTITY amiga "Amiga"> <!ENTITY ados "&amiga DOS"> <!ENTITY hdtbox "<application>HDToolBox</application>"> ]>  <book id="faq"> <bookinfo> <date>$Date: </date> <title>&thisdoc;</title> <releaseinfo>documentation in progress</releaseinfo> <authorgroup> <author> <firstname>Jesper</firstname> <surname>Skov</surname> </author> </authorgroup> <address><email>jskov@cygnus.co.uk</email></address> <copyright><year>1998, 1999</year> <holder>Jesper Skov</holder></copyright> <abstract> <para>This document contains frequently asked questions (and answers) about &linapus; (&linux; for &amiga; &pup; Systems) as well as general documentation of the &linapus; port.</para> </abstract> </bookinfo> <toc></toc> <chapter id="firststop"> <title>First Stop</title> <para> Hello!</para> <para> Welcome to &thisdoc;. I hope you will find what you are looking for... But wait! Before you read on, please consider this plea for help.</para> <para> Given the broad subject, it is unfortunately not possible to cover everything Linux related in &thisdoc;. Only &linapus; issues are covered, and to some extend, a few generic &amiga; issues. This is not entirely bad, because that leaves the remaining (and majority) of documentation issues in the hands of more capable people than myself. What you should expect to find though, are relevant links to other documentation resources so you have somewhere else to go when you get past the first few steps.</para> <para> Even if this document only covers &linapus; related issues, some users (perhaps you are one) will get their first taste of &linux;, an operating system vastly different from ADOS, via &linapus;, possibly reading &thisdoc; as an introduction. Therefore it is imperative that the documentation is relevant, up-to-date and has all the necessary resource links a first time Linux user may need.</para> <para> Given that I, and other people who have used &linapus; for a while, already have working installations, and have sorted out most of the problems faced by a newbie, it is important that <emphasis>you</emphasis> help keeping &thisdoc; up-to-date. While that may sound scary, it shouldn't -- what you are asked to do is:</para> <itemizedlist> <listitem> <para> Point out weaknesses of &thisdoc; so they can be corrected (preferrably with your feedback). </para> </listitem> <listitem> <para> When you figure something out that had you puzzled, write up a few paragraphs about the problem and the solution and submit it to &thisdoc;.</para> </listitem> </itemizedlist> <para> In particular, you should be aware that there is no fancy AI collecting experiences, tips, workarounds, or summarizing discussions from the mailing list. If nobody follows up on a problem, it's likely to remain a problem for the next user. Therefore, if you get help to overcome a problem, please consider taking a bit of time out of your (I'm sure) busy schedule, and write something (a new FAQ entry, a new section, a correction to an existing text) for &thisdoc;.</para> <para> Thanks,</para> <para> Jesper</para> </chapter> <chapter id="introduction"> <title>Introduction</title> <para> The &linux; port for APUS (&amiga; &pup; Systems) was started in 1997 with support from <ulink url="http://www.phase5.de">&p5;</ulink> who provided 3 developer boards to Jes Sørensen, Roman Zippel and Jesper Skov.</para> <para>Initially it seemed that the proprietary information needed to make the port would make a bad mix with the open source model of &linux;. Indeed, it postponed the public release of &linapus; somewhat, but it all worked out in the end. &p5; have approved all the released information and, sparse commenting aside, all source code changes are freely available.</para> <sect1 id="linux-ports"><title>&linux; ports</title> <para>I refer to the following ports of &linux; in this document:</para> <para> <emphasis>&linm68k;</emphasis> The port for the Motorola &cpum68k; CPU family. This is what you would use for running &linux; on an &amiga; without &pup;. It is also the port that &linapus; is based on, since all the drivers are the same.</para> <para><emphasis>&linppc;</emphasis> The port for the Motorola &cpuppc; CPU family. The home of this port is at <ulink url="http://www.linuxppc.org">www.linuxppc.org</ulink>. This port has multi-machine support, including PMAC, PREP, CHRP and partially APUS.</para> <para><emphasis>&linapus;</emphasis> The port targeted at &amiga;s with &p5;'s &pup; hardware. With time, it will be a proper part of &linppc;. It may also become a base for the support of &cpuppc; cards from other &amiga; vendors.</para> </sect1> <sect1 id="document-changes"><title>Document Changes</title> <para>I will try to keep this document up to date, but if you find something that is obsolete or wrong, please let me know. Things marked with <emphasis>FIXME</emphasis> are known to be incomplete or (maybe) wrong.</para> <para> New changes in the document are marked with colors. Recent changes are red, and as the changes age they fade to blue and then black over a period of 14 days or so. Sections containing these colored changes will be dated so they can be easily identified from the table of contents. The colors work fine (IMO) with the default Netscape colors. If you use a customized color scheme, you might want to generate the HTML pages without the colors: use the DocBook <application>db2html</application> and the file <filename>faq.sgml</filename> from the docs directory at &sunsite;.</para> </sect1> </chapter> <chapter id="getting-the-kernel"><title>Getting The Kernel</title> <para> Precompiled kernel images and a special version of &amiboot; (called &boothack;) can be downloaded from &sunsite;.</para> <para> Before you download anything, you should read <xref linkend="working"> and <xref linkend="problems"> to prevent yourself from getting a nasty surprise. Also, I suggest you start by downloading only what is needed to get a minimal system installed (see <xref linkend="installing">) - if this is working you can then download the applications you want to run.</para> <sect1 id="the-kernel-images"><title>The Kernel Images</title> <para> The kernel archives at &sunsite; (see <xref linkend="sunsite">) are named <filename>vmapus-YYMMDD.lzh</filename> and contain three files: <filename>vmlinux</filename> (the actual kernel image), <filename>System.map</filename> (a list of symbols/addresses in the kernel) and <filename>.config</filename> (describing how the kernel was configured).</para> <para>You only need the kernel image to boot &linux;, but the other files may help track down bugs. Please read <xref linkend="dev-kernel-debugging"> for information about how you can use a kernel dump and the <filename>System.map</filename> file to help yourself or others locate a bug.</para> <para> Precompiled kernels are provided for the 2.2.x series kernels (stable release). The 2.3.x kernels are only available in source form. People who want the bleeding edge stuff should compile their kernels themselves (see <xref linkend="dev-recompile">).</para> <sect2 id="included-hardware-drivers"> <title>Included Hardware Drivers</title> <para>The precompiled kernel image includes drivers for the hardware listed below. The drivers are <emphasis>exactly</emphasis> the same as in &linm68k; so they will not work better (or worse, hopefully) and you need to take the same precautions with some of the drivers (e.g., CyberVision) as you would in &linm68k;. Consult the &linm68k; FAQ (see <xref linkend="links">) if you have problems.</para> <para>A list of drivers that are known to <emphasis>work</emphasis> can be found in <xref linkend="working">.</para> <informaltable frame="all"> <tgroup cols="2"> <thead> <row> <entry>DISPLAY</entry> <entry>BLOCK</entry> <entry>CHAR</entry> <entry>NET</entry> <entry>SCSI</entry> </row> </thead> <tbody> <row> <entry>OCS, ECS, AGA, CyberVision, CyberVision/3D, PM2 (CyberVision/PPC) <footnote> <para> The driver included in the precompiled kernel is an old beta. If you want the up-to-date version get the latest sources from the PM2 webpage (see <xref linkend="links">). Don't expect the precompiled version to behave as described on the webpage!</para> </footnote>, RetinaZ3, Clgen</entry> <entry>&amiga; floppy, A1200/A4000 IDE, IDEDoubler, Buddha</entry> <entry>&amiga; serial, &amiga; keyboard, &amiga; mouse, &gvp; IO extender (ser) <footnote> <para> On some machines, the IO extender may cause the kernel to hang at startup. A crude hack can be used to work around this problem - ask on the mailing list for details if necessary.</para> </footnote>, MultifaceIII ser, Whippet</entry> <entry> Ariadne, AriadneII, A2065, Hydra, A1200 PCMCIA/NE2000</entry> <entry> A3000, A4091+A4000T<footnote id="a4000tscsi"> <para>You have to disable the use of BATs to map main memory. Add <option>"nobats"</option> to your kernel options. There are still some stability problems with this driver under &linapus;.</para> </footnote> , BlizzardPPC<footnote id="blzscsi"> <para>You have to disable the use of BATs to map main memory. Add <option>"nobats"</option> to your kernel options.</para> </footnote> , A2091, GVP11 </entry> </row> </tbody> </tgroup> </informaltable> <para>If you have hardware for which you would like to see an <emphasis>existing</emphasis> &linm68k; driver included, please let me know. You should restrict your request to something you need to get your system installed as the precompiled kernel is already pretty big. Some drivers will be include for testing purposes (like sound) and be removed again when they have been reported as working.</para>  </sect2> <sect2 id="included-software-drivers"> <title>Included Software Drivers</title> <para>The kernel also includes these software drivers:</para> <informaltable frame="all"> <tgroup cols="2"> <thead> <row> <entry>FS</entry> <entry>PARTTBL</entry> <entry>PROTOCOLS</entry> <entry>MISC</entry> </row> </thead> <tbody> <row> <entry>affs, dos, ext2, iso9660, minix, nfs, proc, vfat, hfs</entry> <entry>amiga, msdos, mac</entry> <entry>ppp, slip</entry> <entry>ram disk, z2/motherboard swap, loop</entry> </row> </tbody> </tgroup> </informaltable> </sect2> </sect1> </chapter> <chapter id="installing"><title>Installing</title> <para>In this chapter I will try to help you through the steps of installing a &linapus; system. This is based on the &rhppc; system - if you want to install another package distribution or compile applications yourself, you are pretty much on your own. The only reason for describing how to install a &rhppc; system and not &debian; is that &rhppc; seems to be (at the moment) the primary system used by &linppc;. By the way, &rhppc; is not coordinated by &rh; but by &linppc; developers.</para> <para>It might be a good idea to read this entire chapter before you start downloading anything - so you know what is required for what you want to do.</para> <para>If you don't know how to do some of the things mentioned here (or are unclear about something) you should get an install help text. You should be able to find several by looking for links at <ulink url="http://www.linux-m68k.org">www.linux-m68k.org</ulink>.</para> <para>If you have corrections, additions or comments to this, please let me know. Your feedback is important for this chapter since new users (after <emphasis>you</emphasis> there may be others coming this way, you know!) will probably try to follow this - any misinformation or errors no matter how trivial should be corrected.</para> <sect1 id="files-required-for-booting"> <title>Files Required For Booting</title> <para>You need to get files from the following: <xref linkend="sd-misc">, <xref linkend="sd-install-rh">, <xref linkend="sd-boothack">, and <xref linkend="sd-22x">.</para> <para> You should get the following files (leave them in the same directory):</para> <itemizedlist> <listitem><para><filename>misc/kernel-options.txt</filename></para> </listitem> <listitem><para><filename>misc/ramdisk.image.gz</filename> <footnote> <para>The <filename>ramdisk.image.gz</filename> is primarily used to test that &linapus; actually boots. If you know it boots, don't bother downloading it.</para> </footnote></para> </listitem> <listitem><para><filename>boothack/bhYYMMDD.lha</filename></para> </listitem> <listitem><para><filename>2.2.x/vmapus-YYMMDD.lzh</filename></para> </listitem> <listitem><para><filename> install/redhat/apus-rh-ramdiskimageYYMMDD.gz</filename></para> </listitem> </itemizedlist> <para>Unpack the archives (the version of <application>lha</application> I use under &linux; appends the suffix <filename>.lzh</filename> and I'm bound to forget renaming them to <filename>.lha</filename> - so I don't):</para> <screen> lha x bhYYMMDD.lha lha x vmapus-YYMMDD.lzh </screen> <para>Leave the ram disk compressed, or it will not be usable.</para> </sect1> <sect1 id="booting-linux-apus"><title>Booting &linapus;</title> <para> This section describes how to boot the kernel. The basic command required to boot &linapus; using a ram disk as main file system is:</para> <screen> bootstrap --apus -k vmlinux -r ramdisk.image.gz root=/dev/ram </screen> <para>The <option>root=/dev/ram</option> option tells the kernel to read its data from the ram disk, <option>-k</option> specifies the kernel image to boot, <option>-r</option> the ram disk file and <option>--apus</option> that the &cpuppc; should be the CPU starting the kernel.</para> <para>The above is how you would boot on a <emphasis>simple system</emphasis>. When issuing the command <command>bootstrap</command> you may need additional parameters (at the end) for the kernel to work on your system - this is just the same as if you were booting a &linm68k; system. Display selection, display resolution, SCSI driver options and other things are controlled by such additional options.</para> <para> There are two specific &linapus; kernel options:</para> <itemizedlist> <listitem><para><option>60nsram</option></para> <para>Use this to remove RAM waitstates. It requires 60ns RAM.</para> </listitem> <listitem><para><option>nobats</option></para> <para>Use this to prevent the use of BATs for mapping of main memory. Selecting this incurs a small performance overhead, but some drivers depend on each memory page being individually mapped (A4000T/A4091 SCSI drivers).</para> </listitem> </itemizedlist> <para>Other kernel options exist, but are shared with &linm68k; and other ports so I don't describe them here. One of the files you should download (<filename>kernel-options.txt</filename>) describes the options you can use. The &linm68k; website/FAQ should also contain some general information about the boot options.</para> <para> A ram disk image is used to get started. The ram disk contains a minimal &linux; system from which you prepare your disks. When you have done this (described in sections below), you will normally use <option>root=/dev/xxx</option> (where xxx is the root partion) to boot your &linapus; system.</para> <para><emphasis>Notice that booting the &linapus; kernel might blank the display for as long as 30 seconds depending on the &cpuppc; speed.</emphasis></para> <para>Some people have reported problems with copying the ram disk (and kernel) to RAM: before booting and must use a disk partition for the files. Others need to copy the files to RAM:, especially &blzppc; owners who use SCSI disks.</para> <para>Additional to options for making your hardware run smoothly with &linux;, you may need to restrict your memory configuration for &linapus; to work correctly.</para> <sect2><title>Booting via GUI</title> <para>Duncan Gibb has modified Samuel Devulder's MUIRexx-based UAEWB launcher to work with &linapus;. I must admit that I don't know much about either. (Duncan, when you get past your exams, please send me some text). </para> </sect2> <sect2><title>&linapus; Memory Restrictions</title> <para> &linapus; only supports one block of primary memory which should be the memory on the &pup; board. It would be possible to support mutiple blocks, but since there is such a big performance penalty in using other system memory than the one on the &pup; board, it doesn't make sense.</para> <para> The problem is that &linux; uses memory much more aggressively than &ados; so all memory will be used constantly. Because of this it is not possible to prioritize memory blocks as it can be done under &ados;. This means that you cannot guarantee that the most CPU intensive applications actually run in the fastest memory block in the system. For this reason, &linapus; only support one block of primary memory -- the fastest. See <xref linkend="fastswap"> for a way of using additional memory.</para> <para> If you have multiple memory blocks, the one on the &cybppc;/&blzppc; will usually have the highest priority and be selected by default. Unfortunately, this is not foolproof and you may have to explicitly define the block to be used.</para> <para>You control the memory &linux; can see by using a memory config file: add <option>-m <filename>file</filename></option> after the <option>--apus</option> option. This file should contain 2 lines: on the first the size of your chip memory, on the second the starting address of the memory and its size. Here's a single example.</para>  <screen> 2097152 0x08000000 33030144 </screen> <para>The format of memory files actually allow more memory blocks to be specified (since it was created for &linm68k;), but <emphasis>only one</emphasis> memory block can be used in &linapus;. If you have more than one block of memory in your system, you must specify the block located on the &cybppc; or &blzppc; card.</para> <para>You should be able to get the required numbers from showconfig or a similar tool under &ados;.</para> <para>Notice that the size of the memory is 512kB less than what you would expect (33030144 is 31.5MB). This is normal <emphasis>and required</emphasis>. The 512kB block is used to hold the &cpuppc; exception vector table and other &p5; stuff.</para> <sect3><title>ROM Shadowing</title> <para>If you are using the Shadow hardware on your &p5; &cybppc; or &blzppc; board to remap the &ados; ROM to RAM, you should either disable this before booting &linapus; or make sure the memory size reflects this mapping: the memory size reported by bootstrap should be 1MB smaller than the amount of RAM in your system. If it is only 512kB smaller, you have to use a memfile, specifying the total amount of RAM less the 1MB.</para> <para>The newer kernels (980725+) will detect the ROM shadowing (based on the memory size) and will avoid that chunk of memory. This means 512kB of your memory will remain unused in &linapus;. <emphasis>If you do not subtract the 512kB when specifying the size in a memfile, the kernel will not boot!</emphasis></para> </sect3>  <sect3 id="fastswap"><title>Memory-to-Memory Swapping</title> <para> Even though only one block of memory can be used for primary memory in &linapus; you can use other memory resources as a fast swapping device. Using slower memory for swapping makes sense; your applications are always running in the fast primary memory on the &pup; board, but the slower memory is still providing a much faster page swapping service than the harddisk would.</para> <para> You specify a block of memory for swapping by adding a line to the memory file (or by relying on the default &ados; priority ordering of the memory blocks). On my box, I have 32MB on the &cybppc; and 8MB on the motherboard of my A4000. The default &ados; ordering matches this memory file:</para> <screen> 2097152 0x08000000 33030144 0x07800000 8388608 </screen> <para> Again, the default &ados; priority ordering may do the correct thing for you. If not, you have to use a memory file.</para> <para> After booting, you need to tell &linux; to use the new swapping device. First you must add a new device node:</para> <screen> mknod /dev/fastram b 37 4 </screen> <para> Each time you boot you have to initialize the memory area (it doesn't keep its state over reboot as your swap partition does), and enable it with a higher priority than the swap partition (put the lines in <filename>/etc/rc.d/sysinit</filename> or similar). </para> <screen> mkswap /dev/fastram swapon -p1 /dev/fastram</screen> <para> In the above only a single memory chunk is used for swapping. The z2ram device can only handle one chunk at the moment. However, it can select other than the second chunk of the memory list; minor numbers 4, 5, 6, and 7 select memory chunks 2, 3, 4, and 5 respectively, chunk 1 being used as primary memory.</para> </sect3>  </sect2> </sect1> <sect1 id="the-first-step"><title>The First Step</title> <para> Before you go any further and start downloading packages, you should make sure that you can actually boot &linapus;.</para> <para> Get the required files for booting and follow the boot instructions above.</para> <para> If all goes well &linapus; should boot, displaying a picture of an (alcoholic :) penguin (called Tux) in the upper left corner of the screen. Text should be output, showing the progress of the boot, eventually leaving you with a # prompt and a blinking cursor (unless you boot with debug=<whatever> in which case you will not see the text, only Tux and the prompt).</para> <para> Your disk partitions should be recognized, notifying you of this fact with some output similar to:</para> <screen> Partition check: hda: hda1 hdb: hdb1 hdb2 hdb3 hdb4 </screen> <para> This is a good sign as it means the disk driver is probably working. Depending on your hardware configuration you might not see this. Either because there exists no driver for the disk controller, or because the driver has not been included in the prebuilt kernel you booted. In both cases, report your finding to the &linapus; kernel mailing list for advice.</para> <para> The ram disk contains a few tools that allow you to mount disks to see if they work as expected. This ram disk was used in an older installation scheme, but unless you really know what you do, you should use the &rh; installer.</para> <para> If you got this far, it should be safe for you to start downloading packages for a proper installation of your &linapus; system. Good luck!</para> </sect1> <sect1 id="preparing-partitions"><title>Preparing Partitions</title> <para><emphasis>Text by Thomas Lohmann</emphasis></para> <para>The partitions for installing &linapus; should be created using &hdtbox; which is included in &ados; since version 2.x. You need at least two partitions, one for SWAP (as big as your memory is) and one for ROOT. You have to set the advanced options using &hdtbox; to ON and set the filesystem type to "CUSTOM FILE SYSTEM", the identifier has to be set as follows:</para> <itemizedlist> <listitem><para> 0x4c4e5800 (LNX/0) For all major &linux; partitions.</para> </listitem> <listitem><para> 0x53575000 (SWP/0) For the swap partition.</para> </listitem> </itemizedlist> <para>You can also set "Reserved Blocks at" to 0 for both beginning and end, but this should not be necessary.</para> </sect1> <sect1 id="installing-a-redhat-system"> <title>Installing a &rh; System</title> <para>You can get precompiled &rh; &rpm; packages from www.linuxppc.org (see <xref linkend="links">) or its mirrors. You can also buy the CD-ROM (details at the WEB site). <emphasis>&rhppc; does not explicitly support &linapus;. None of the &linapus; developers are affiliated with the &rhppc; developers. This help is offered "AS IS" -- without any guarantees of your success.</emphasis></para> <sect2><title>&rhppc; R5/1999 Installation</title> <para>See <ulink url="http://users.iol.it/marco.dvv/marcus/htal.html"> users.iol.it/marco.dvv/marcus/htal.html</ulink> for an installation guide.</para> </sect2> <sect2><title>&rhppc; Installation</title> <para><emphasis>Text by Ken Tyler</emphasis></para> <sect3><title>Overview</title> <para>The &rhinstaller; simplifies the process of partitioning, formatting installing and configuring the &linux; &rhppc; distribution.</para> <para>No previously installed &linux; is required, the installation is started from &ados; by booting a kernel with the &linapus; ram disk image as the root filesystem.</para> <para> The &rhinstaller; has been used to install from a hard disk partition to other partitions on the same drive. Christophe Decanini reports that CDROM, FTP and NFS work.</para> <para>Note: See <xref linkend="software-with-known-problems"> for a list of applications that are known to fail.</para> </sect3> <sect3><title>Requirements</title> <itemizedlist> <listitem><para> A kernel.</para></listitem> <listitem><para> The latest &linapus; &rhinstaller; ram disk image (usually named <filename> apus-rh-ramdiskimageYYMMDD.gz</filename> in <xref linkend="sd-install-rh">).</para> </listitem> <listitem><para> &rpm;s, base files and <filename>README.installer</filename>. Available on the &linux; &rhppc; CD-ROM or from <ulink url="ftp://ftp.linuxppc.org">ftp.linuxppc.org</ulink> and mirrors.</para> <para> The base files required are <filename>comps.pmac</filename>, <filename>hdlist</filename>, <filename>skeleton.cgz</filename> and <filename>uglist</filename>.</para> </listitem> <listitem><para> A few moments spent reading this docment, especially the Problems at the end of this section.</para> </listitem> </itemizedlist> </sect3> <sect3><title>What is an &rpm;?</title> <para> &rpm; is the acronym for &rh; Package Manager. This is a standalone program that installs software on to a &linux; system. Files intended for use by &rpm; have the extension <filename>.rpm</filename>. The &rhinstaller has a library version of the RedHat Package Manager in the install ramdisk.image.</para> </sect3> <sect3><title>Hard Disks</title> <para>The &rhinstaller; can partition and format hard disks, but depending on which install method you use you might need to partition your hard disk first with &hdtbox;. On a single drive system, an AFFS &ados; partition is needed to hold the &rpm;s in addition to the required &linux; and swap partitions. On a system with two or more drives, or when using the other install methods the installer can do the partitioning and formatting of the drive(s).</para> <para>On the AFFS drive or partition a directory <filename class=directory>RedHat</filename> with subdirectories <filename class=directory>RPMS</filename> and <filename class=directory>base</filename> should be created. The <filename class=directory>base</filename> directory should hold the <filename>comps.pmac</filename>, <filename>hdlist</filename>, <filename>skeleton.cgz</filename> and <filename>uglist</filename> files. The <filename class=directory>RPMS</filename> directory is the place for the collected &rpm;s.</para> <para> The suggested &rh; minimum system is about 25MB of &rpm;s which needs about 70MB of &linux; disk space.</para> </sect3> <sect3><title>Components "comps" file and <filename class=directory>RPMS</filename></title> <para> Read the <filename>README.installer</filename> for info on the <filename>comps.pmac</filename> file format. Basically there are two types of line; separator lines and &rpm; prefix lines. Separator lines start with a digit or the word 'end' and divide the &rpm;s into groups, &rpm; prefix lines are partial &rpm; names. An indented &rpm; prefix line implies that the &rpm; specified by the preceding non-indented line is required. If the <filename>comps.pmac</filename> file has entries for &rpm;s that don't exist in the <filename class=directory> RPMS</filename> directory the installer complains about them but will work, but to avoid saying OK to many warnings edit the <filename>comps.pmac</filename> file to include only the &rpm;s you have.</para> <para>The long filenames of some &rpm;s are chopped at the &amiga; 32 character limit but this is not a problem since &rpm; will scan the packages for their full name.</para> </sect3> <sect3><title>Installing</title> <para>Copy the <filename>apus-rh-ramdiskimageYYMMDD.gz</filename> to RAM: and boot specifying:</para> <screen> -r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram </screen> <para>in addition to the usual <option>--apus</option>, <option>-k</option>, and <option>-m</option> options as required.</para> <para>I use (all on one line) :</para> <screen> boothack --apus -v -d -m memfile -k ram:vmlinux -r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram </screen> <para>If all goes well a window asking if you have a color monitor will appear.</para> <para>(Respond to the windows with <keycap>CR</keycap> to enter, <keycap>SPACE</keycap> to toggle on/off and <keycap>TAB</keycap> to move between buttons, cursor arrows to move up and down lists.)</para> <para>Now comes a succession of windows guiding you through the installation. Reply to these to suit your system. Choose install at the install/upgrade window. Eventually you should get to the window asking what packages to install. Select what you require or the "everything" option at end of the list.</para> <para>After the Package install finishes there may be much disk activity as the &rpm; database is created.</para> <para>A few more windows, networking timezone and root password.</para> <para>Finally an "OK to reboot" screen should appear but wait till the disk activity stops before rebooting.</para> <para> During the the install, <keycap>CTRL</keycap>-<keycap>Z</keycap> brings a shell up, entering <command>exit</command> returns you to the installer. <keycap>ALT</keycap>-<keycap>F1</keycap> to <keycap>ALT</keycap>-<keycap>F4</keycap> select installer, a shell, installer log and kernel log virtual consoles. To get <keycap>F11</keycap> to <keycap>F20</keycap> use <keycap>SHFT</keycap>-<keycap>F1</keycap> etc.</para> </sect3> <sect3><title>Required RPMS</title> <para> To create a list of the suggested required &rpm;s for a minimum system, take the &rpm; prefixes in the '1 *beforeskel*' and the '1 Base' sections of the <filename>comps.pmac</filename> file and expand them into the full &rpm; name as contained in the <filename class=directory>RPMS</filename> directory.</para> </sect3> <sect3 id="install-problems"><title>Problems</title> <para>Flashing console problem. The current CD (as at 27-Oct-98) writes an /etc/inittab that attempts to start X at the default run level of 3 rather than run level 5. As kernels from 2.1.120 to the 981026 release have problems with X on some hardware, the result is alternating flashes of login screens and blank X screens. The same thing also happens if the default run level is set to 5 and the information in the XF68Config file is incorrect. To avoid this, either get a 981031 or newer kernel, or fix the installation: when the installation finishes don't respond to the "Congratulations" window but hit ALT-F2 and edit <filename>/mnt/etc/inittab</filename>. All that needs to be done to <filename>/mnt/etc/inittab</filename> is to swap the comment '#' char on the last two lines of the file. To run any of the newly installed editors you need to specify a full path, the installed system is on <filename class="directory">/mnt</filename>. Now hit ALT-F1 and confirm the "Congratulations" window. Thanks to Kolbjørn Barmen for suggesting this approach. If you have already installed the X components and are seeing the flashing console, you need to login and edit <filename>/etc/inittab</filename> and make the above change.</para> <para><emphasis><From Douglas Valentine></emphasis> As it can be difficult to login through the flashing (although it can be done) it is easier to boot in single user mode to fix the problem. To do this add the parameter "single" to the end of your normal boothack parameters and boot Linux as normal. Linux will then boot in single user mode, which is a special maintenance mode, instead of booting up and displaying a login prompt, it will come to a prompt: <literal>sh-2.0.3#</literal> Now type <literal>pico /etc/inittab</literal> and make the change explained above, save the changes and then restart Linux as normal (remember to remove the "single" parameter again). </para> <para> The first version of the installer was incorrectly named <filename>apus-rh-ramdisk.image130698.gz</filename>, should have been called <filename>apus-rh-ramdisk.image980613.gz</filename>.</para> <para>NOTE: <filename>apus-rh-ramdisk.image981003</filename> requires the <filename>comps</filename> file to be named <filename>comps.pmac</filename>, for earlier versions of the installer, rename <filename>comps.pmac</filename> to <filename>comps</filename>.</para> <para> If you have a 4.2 CD February 98 use <filename>apus-rh-ramdisk.image130698.gz</filename>, if you have the 5.0 CD or try the other install methods use <filename>apus-rh-ramdisk.image981003</filename>. The 130698 installer has problems with the 'noarch' files in the 5.0 distribution.</para> <para> Three of the &rpm;s on the 4.2 CD have errors when installing. <filename>dailyscript-3.1-2.ppc.rpm</filename> writes a message over the progress screen, <filename>latex2html-96.1.revh-4.ppc.rpm</filename> and <filename>xmahjongg-2.0-1A.ppc.rpm</filename> fail with install script failed.</para> <para> I have yet to do a full install from the 5.0 CD. Installing the suggested base was free of errors.</para> <para> Some users have a reported a 'missing kernel error' when attempting to install from downloaded &rpm;s. The installer tries to put a kernel into the <filename class=directory>/boot</filename> directory. There is no reason to do this as the kernels available on linuxppc.org are not &linapus; kernels. To avoid this edit the <filename>comps.pmac</filename> file and remove the two (4.2) or three (5.0) lines <filename>kernel-prep</filename>, <filename>kernel-pmac</filename>, <filename>kernel-pmac-modules</filename>.</para> <para>Comments, feedback about success or failure most welcome, I read the &linapus; list daily.</para> </sect3> </sect2> <sect2><title>&rhrc; Installation</title> <para> &rh; has released a CD set named Linux Rough Cuts, containing (unsupported) &rh; ports for (among other CPUs) &cpuppc; and &cpum68k;. The &cpuppc; installation is intended for MkLinux, but it's possible to use it for &linapus;.</para> <para> Basically you should follow Ken's instructions above. There are a few differences, primarily because the &rhrc; CD does not contain all the required install files. But follow the below instructions, and you should come out of it OK anyway.</para> <para> Get the file <filename>rh-roughcuts-981108.tgz</filename> from <xref linkend="sd-install-rh">. It contains what you need to get started.</para> <para> The layout of the &rhrc; CD is wrong (for the &linapus; installer), and is missing files (probably because it's intended to be used from MacOS). You have to create a correct layout. You can do this in at least two ways; 1) install via FTP and create the correct layout on another Linux box using soft links (I did this) 2) install from harddisk, having copied the CD contents to a harddisk and added the extra bits.</para> <para> Below the tree structure of the directory I created on Concubine for installation on Cyber (-> is a soft link to the file or directory on the &rhrc; CD). During installation I set the FTP directory to the path containing <filename>RedHat</filename> you see as the top node below.</para> <screen> `-- RedHat |-- RPMS -> /mnt/cdrom/RedHat/RPMS |-- TRANS.TBL -> /mnt/cdrom/RedHat/TRANS.TBL |-- base | |-- RedHat -> /mnt/cdrom/RedHat/ | |-- TRANS.TBL -> /mnt/cdrom/RedHat/base/TRANS.TBL | |-- comps.pmac | |-- hdlist -> /mnt/cdrom/RedHat/base/hdlist | |-- skeleton.cgz | `-- uglist |-- ppc -> /mnt/cdrom/RedHat/ppc `-- rpmcontents.gz -> /mnt/cdrom/RedHat/rpmcontents.gz </screen> <para> The structure is found in the <filename>rh-roughcuts-981108.tgz</filename> archive; you might want to use it as a base. If you create it yourself, there are three files in there that you need to include:</para> <itemizedlist> <listitem><para><filename>comps.pmac</filename> The <filename>comps</filename> file from the base directory of the disk. The two &rpm; packages <emphasis>MAKEDEV</emphasis> and <emphasis>dev</emphasis> have been moved down as the last to be installed due to some problem I couldn't track down.</para> </listitem> <listitem><para><filename>skeleton.cgz</filename> The skelton file from the &rhppc; installation containing a few extra files.</para> </listitem> <listitem><para><filename>uglist</filename> The skelton file from the &rhppc; installation.</para> </listitem> </itemizedlist> <para> When you have this set up, installing is done exactly as with the &rhppc; CD. <note><para>The text printed out before the login prompt is from the &linppc; skeleton, so it is somewhat misleading...</para> </note></para> </sect2> </sect1> <sect1 id="installing-a-debian-system"> <title>Installing a &debian; System</title> <para>You can get precompiled &debppc; &deb; packages from www.debian.org (see <xref linkend="links">) or its mirrors. Currently no &cpuppc; version of the &debian; CD distribution exists.</para> <sect2><title>Installation</title> <para><emphasis>Text by Michel Dänzer</emphasis></para> <para>First of all, be aware that installing &debian; is quite a bit harder at the moment than installing &rhppc;. I mention this so nobody downloads lots of stuff and then has to give up frustrated. There is no CD-ROM release until now, the guys at &debppc; want to wait until it's virtually equal to the i386 &deb;. However, if you've got the time and will to experiment a little, give it a go! You won't be deceived :-)</para> <para><emphasis>Please read all the instructions carefully before you start.</emphasis></para> <sect3><title>Preparing the filesystems</title> <para>You need to have an empty ext2 partition, which will be the root partition. You will probably need a swap partition and maybe others as well. It's up to you how you arrange things. You might want to read <xref linkend="preparing-partitions"> first.</para> </sect3> <sect3><title>Installing the base filesystem</title> <para>Get a base tarball. I have uploaded one to sunsite, it should be in <xref linkend="sd-install-deb">. Get the <filename>rd-deb-install.gz</filename> ramdisk there. You might want to download or at least look at the other files there as well.</para> <para>Unpack the base tarball. I'll quickly describe how to do this with the <filename>rd-deb-install.gz</filename>. </para> <para>Boot the ramdisk. Init will ask you to enter the runlevel, type 'S' and press enter there. Now you'll see a rather ugly prompt, however, it's bash, so you have all the commodities like command history etc. Format the root partition (I call it /dev/sda2 here because that's my root partition at home; replace it with <emphasis>your</emphasis> root partition): </para> <screen> mke2fs /dev/sda2 </screen> <para>Mount the soon-to-be root partition at /mnt/root: </para> <screen> mount -t ext2 /dev/sda2 /mnt/root </screen> <para>Mount the Amiga partition containing the base tarball at /mnt/amiga (Again, replace /dev/sda4 with your partition ;): </para> <screen> mount -t affs /dev/sda4 /mnt/amiga </screen> <para>CD to the base tarball's directory and unpack it with: </para> <screen> tar xvzpf base2_1.2.0.11.4_1998-10-15.tgz -C /mnt/root </screen> <para>The <option>p</option> switch is vital, it sets all permissions correctly.</para> <para>Remove the <filename>unconfigured.sh</filename> script which would prevent the thing from booting (Note: if you're unlucky and have the first version of <filename> rd-deb-install.gz</filename>, you will have to use <filename>/mnt/root/bin/rm</filename>): </para> <screen> rm /mnt/root/sbin/unconfigured.sh </screen> <para>You need to create <filename>/mnt/root/etc/fstab</filename>, or else init won't be able to mount the filesystems at boot time. You can use <filename>joe</filename> to do that: </para> <screen> joe /mnt/root/etc/fstab </screen> <para>Press CTRL-K and then H for help. CTRL-K X to save the file.</para> <para><emphasis>FIXME: Unfortunately, there is no template fstab in this base tarball anymore.</emphasis> If you don't know how to set it up, refer to other FAQs (I would be glad if someone could add an example here - or maybe I'll do it sometime :).</para> <para>Now you're set for a first boot into your shiny new &debian; root partition! Remember to unmount all filesystems before rebooting.</para> <screen> umount /mnt/root umount /mnt/amiga </screen> </sect3> <sect3><title>The first boot</title> <para>It should boot right through to the login screen. You must login as root.</para> <para>Now you can start installing additional packages. All the needed stuff like pppd, ftp, etc. is there, so the main problem remaining is probably setting up pppd. Try <application>pppconfig</application>, a tool for that purpose with a User Interface. If that doesn't work, bad luck, check out the PPP-Howto at <ulink url="http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html"> http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html</ulink> </para> <para>Once this works, <application>dselect</application> can download the packages you want automatically via FTP. Just choose FTP as the installation method. The main server is ftp.debian.org, but you'll probably prefer a mirror close to you. Read <ulink url="http://www.debian.org/misc/README.mirrors"> http://www.debian.org/misc/README.mirrors </ulink> for a list. There's also a mirror at &sunsite; in <filename class="directory"> /mirrors/ftp.debian.org</filename>. The distribution directories are <filename class="directory"> debian/dists/unstable/main</filename> and optionally <filename class="directory"> debian/dists/unstable/contrib</filename> and <filename class="directory"> debian/dists/unstable/non-free</filename>. The location of the non-us files varies from mirror to mirror.</para> <para>You should update the libc and libstdc++ packages ASAP. This may break some packages, just update them to the latest version. E.g. you'll probably have to update the dpkg and tar packages.</para> <para>Congratulations, you should be using &debppc;! ;-)</para> </sect3> <sect3><title>X</title> <para>Unfortunately, you can't get X to work with the packages from the official FTP archive. Try the packages Sven built for you in <xref linkend="sd-deb">. You need at least the xbase, xbase-clients, xfonts-base, xlib6g, xserver-common, xserver-fbdev and xterm packages. Install them directly with dpkg:</para> <screen> dpkg -i <path to the files>x*.deb </screen> <para>You also need a window manager; <filename>twm</filename> in <xref linkend="sd-deb"> is a very simple one to start, there are lots in the official archive.</para> </sect3> </sect2> </sect1> <sect1 id="software-with-known-problems"> <title>Software With Known Problems</title> <para>Some &rhppc; packages don't mix well with &linapus;. Please help me keep this list up to date so people don't have to download useless packages.</para> <itemizedlist> <listitem><para> The <filename>kbd*</filename> packages messes up the keyboard layout. Do not install them. Supposedly there are &amiga; keyboard patches for the recent kdb packages. I have not tried it myself though. </para> </listitem> <listitem><para> <application>Emacs-nox</application> core dumps. This is a generic problem. The <application>emacs</application> compiled with X libs works fine.</para> </listitem> <listitem><para> <application>Gpm</application> requires a small patch to be working. This is available from <xref linkend="sd-misc"> (provided by Holger Jakob). The patch is not needed for <application>Gpm</application> version 1.16 and above. You may also have to add <literal>MOUSETYPE='BUSMOUSE'</literal> to <filename>/etc/sysconfig/mouse</filename>.</para> </listitem> <listitem><para> <application>X</application> had a bug causing eterm, enlightenment, wmaker, mozilla, etc. to crash when run on afb (i.e., no graphics card). This has been fixed now. Sven has provided a binary of the X server for Debian (may also work for other distributions): <ulink url="http://dpt-info.u-strasbg.fr/~luther/xfree/XF68_FBDev_3.3.4_afb_fix.gz"> http://dpt-info.u-strasbg.fr/~luther/xfree/XF68_FBDev_3.3.4_afb_fix.gz</ulink> </listitem> </itemizedlist> </sect1> </chapter> <chapter id="applications"><title>Applications</title> <para> This chapter contains a few random notes on applications for &linapus;. </para> <para> You can get precompiled software for a complete system in both &rh; and &debian; packages (see <xref linkend="links">). The thing to remember when looking for applications is that &linapus; is binary compatible with &linppc; so you should have no problems finding software.</para> <para>Some commercial applications are also available for &linux;, but only in binary form. You would have to persuade the company to start shipping &cpuppc; compiled binaries in that case. I can imagine some of the other &linppc; sites would be coordinating such efforts, or at least it seems like a good idea to do.</para> <sect1 id="x"><title>X</title> <para>In order to run &x; you need to get a version of the &x; server compiled for &cpuppc; with support for the &amiga; hardware. Luckily, such a server is provided by Geert Uytterhoeven at <ulink url="http://www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz"> www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz </ulink> (You might find a newer version than this). </para> <para> You should also get <application>fbset</application> from Geert's site: <ulink url="http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz"> www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz</ulink> (again, there may be a newer version). This file may also be useful: <ulink url="http://www.cs.kuleuven.ac.be/~geert/bin/fb.modes.gz"> www.cs.kuleuven.ac.be/~geert/bin/fb.modes.gz</ulink> </para> <para>Unzip the &x; server and copy it to <filename>/usr/X11R6.3/bin/X</filename>.</para> <para>Now get the example <filename>XF86Config</filename> file from <xref linkend="sd-misc"> and copy it to <filename>/etc/XF86Config</filename>.</para> <para>Next, you have to create some &amiga; specific devices which are not included in the &rhppc; packages:</para> <screen> cd /dev mknod fb0current c 29 0 mknod amigamouse c 10 4 ln -s fb0current fb0 ln -s amigamouse mouse </screen> <para>Now you should be ready to start up &x; by issuing the command "<application>startx</application>".</para> <sect2><title>&x; and graphics cards</title> <para>There are a few more details to sort out if you want to run &x; on a graphics card. This text is specific to CyberVision and CyberVision/3D -- but it might help you get &x; running on other cards. Please let me know of your success if you try that.</para> <para>Note: You have to use the same pixel clock under &linapus; as you use under &ados;</para> <para> <emphasis>Text by Jeffrey W. Davis</emphasis></para> <para>I just wanted to inform everyone that &linapus; and the CV64 is working. I do not have the CV64/3D, but apparently it is also working. From what I have seen for the CV64/3D you need to substitute <option>"virge"</option> for any instance where I mention <option>"cyber"</option>.</para> <para>(The frame buffer label <option>"cyber"</option> selects the CyberVision64 driver and <option>"virge"</option> the Cybervision64/3D driver.)</para> <para> I use a simple boot script as follows:</para> <screen> copy bootstrap ram:boothack boothack --apus -v -k ram:vmlinux root=/dev/hda3 video=cyber:1024x768-8 </screen> <para>Apparently, only resolutions understood by &linux; work at present. Therefore, you should choose <option>640x480</option>, <option>800x600</option>, or <option>1024x768</option> in the above statement. I believe all of them have been reported to work. I'm sure that there are others, but I haven't done much experimentation at this point.</para> <para>Make sure that before you boot &linapus;, that your CyberGfx video mode matches what you have selected to boot &linapus;. I believe the two key factors in the command line are the <option>-v</option> and <option>video=</option> options. You should be able to modify the rest to suit your configuration.</para> <para>Once you have successfully booted &linux; you will see the penguin drawing and probably a much higher resolution that what you have seen before.</para> <para>To run &x; you will need to specify the resolution in the <filename>/etc/XF86Config</filename> file. There is an example in the same directory as where you found Geert Uytterhoeven's &x; server. To figure out what parameters you need, use "<command>fbset -x</command>" <footnote> <para>You will also find <application>fbset</application> in the, by now, famous directory with Geert Uytterhoeven's &x; server.</para> </footnote> which will show you what you are currently using. If you are running in an interlaced mode, the <application>fbset</application> program will show you values that your monitor will not actually support. BUT... these values will work properly. Simply LIE about the scanrate in your monitor definition in the <filename>XF86Config</filename> file. It will work. Use the values returned from <application>fbset</application> and you should be able to start X with no problem. <footnote> <para>I'd like to see this paragraph rewritten - I wouldn't want someone accidently blowing up their monitor. Users, do be careful! -Jesper</para> </footnote></para> <para>If I use the same resolution for everything, with only one resolution specified for X everything works great. Good luck! Really... it works!</para> </sect2> <sect2><title> Custom XF86Config for CyberGfx users</title> <para><emphasis>Text by Jeff Crystal</emphasis></para> <para>The format for a modeline statement in XF86Config is as follows:</para> <screen> modeline NAME Clock HR SH1 SH2 HL VR SV1 SV2 VL </screen> <para>where Clock is the pixel clock in Mhz, HR is visible Horizontal resolution, SH1 is the start of the horizontal sync pulse and SH2 is the end, HL is the total Horizontal line length, VR is visible vertical resolution, SV1 and SV2 are the start and end of the sync pulse and VL is the total vertical length.</para> <para>To convert a CGX screen mode to X11, folow these steps.</para> <procedure> <step> <para>Run CGXMode in prefs</para> </step> <step> <para>Select the video mode that you would like to use and click Edit</para> </step> <step> <para>Compute the values for the modeline statement as follows:</para> <screen> Modeline "Name" PC HR HR+HPO HR+HPO+HPL HR+HSL VR VR+VPO VR+VPO+VPL VR+VSL </screen> <para>where:</para> <screen> PC = Pixel Clock in Mhz (i.e. 40000000Hz is entered as 40) HR = Horizontal Resolution HPO = Horizontal Pulse Offset HPL = Horizontal Pulse Length HSL = Horizontal Sync Length VR = Vertical Resolution VPO = Vertical Pulse Offset VPL = Vertical Pulse Length VSL = Vertical Sync Length </screen> </step> </procedure> </sect2> <sect2><title>&x; on PAL-lace or NTSC-lace screens</title> <para> <emphasis>Text by Marco De Vitis</emphasis></para> <para> You have to start &linux; in the screenmode you want to use, through the <option>"video=amifb:pal-lace"</option> or <option>"video=amifb:ntsc-lace"</option> options on the bootstrap command line; you can then start &x; making it use the current screenmode. If you already followed the instruction about running &x; above, the only thing you need to do is edit your <filename>/etc/XF86Config</filename> file so that the last section "Screen" only contains one "Display" subsection about the "default" mode:</para> <screen> SubSection "Display" Modes "default" EndSubsection </screen> <para> You can alternatively use Geert Uytterhoeven's <filename>XF86Config.pmac</filename> file found at <ulink url="http://www.cs.kuleuven.ac.be/~geert/bin/XF86Config.pmac.gz"> www.cs.kuleuven.ac.be/~geert/bin/XF86Config.pmac.gz </ulink> decompressing it and copying it in your system as <filename>/etc/XF86Config</filename>, as it is already set up like that. But you'll probably need to edit it anyway to make it work, changing the line:</para> <screen> Device "/dev/adbmouse" </screen> <para>to:</para> <screen> Device "/dev/mouse" </screen> <para> Please note that &x; won't be much usable in 640x400 or even 640x512, and the current (at the time of writing) version of <application>XFree86</application> doesn't support the "Virtual" option for the "default" mode, but it will do it in the upcoming version 3.3.3, allowing you to have a virtual screen bigger than your actual screensize.</para> </sect2> <sect2><title>Exotic &x; problems :)</title> <sect3><title> VGA mode sync problem</title> <para> <emphasis>Text by Matthias Goerdeler</emphasis></para> <para> After installing &x; for use with AGA vga-mode (just use the <filename>XF86Config</filename> found in <xref linkend="sd-misc">) as described earlier I could start &x;, but the monitor just didn't sync. So if your problem is that X does not start, this will probably not help you.</para> <para> I got my monitor to sync after changing the line <emphasis>A</emphasis> to line <emphasis>B</emphasis> in the monitor section of <filename>XF86Config</filename>:</para> <screen> [A] HTimings 640 760 804 916 [B] HTimings 640 750 804 916 </screen> <para> It should be pointed out that I do not know how to calculate the correct timing values, it was just 'try and error'. And it is not even sure that this will help you if you run into the same problem as I did. But you could give it a try and report your findings to the linux-apus mailing list.</para> </sect3> </sect2> </sect1> <sect1 id="compiling-applications"> <title>Compiling Applications</title> <para>You can also compile many applications yourself as the source code is often freely available. This is likely to be necessary if you want to use an application that is not maintained by either the &rhppc; or &debian; teams, as the application author(s) would probably only supply a precompiled version of the application for the ix86 architecture.</para> <para> Some applications need Linux header files to build. These are normally found in <filename class=directory>/usr/include</filename> in the directories <filename class=directory>asm</filename> and <filename class=directory>linux</filename>. When using &linapus; the header files installed by e.g. &rhppc; should be OK for most applications. However, if you decide to replace the default header files with &linapus; specific header files you must also include the directory <filename class=directory>/usr/include/asm-m68k</filename> which must be either a copy of the <filename class=directory>linux/include/asm-m68k</filename> directory or a link to it.</para>  </sect1> </chapter> <chapter id="working"><title>Working Hardware And Drivers</title> <para>When I get reports of hardware configurations that are known to work with &linapus; I put them in this section. You can match these against your own configuration to get an idea of whether &linapus; will work on your box.</para> <para> Note that things listed here are not necessarily included in the precompiled kernels.</para> <para>In comments are listed the people who reported the information - if you have information about a driver currently not on this list (or conflicting information) please let me know.</para> <para>&cybppc; and &blzppc; boards:</para> <itemizedlist> <listitem><para> A4000/o3o with &cybppc; &cpu604;@150MHz (Jesper Skov).</para> </listitem> <listitem><para> A4000/o4o with &cybppc; &cpu604;@200MHz (Jeffrey W. Davis).</para> </listitem> <listitem><para> A4000/??? with &cybppc; &cpu604;@233MHz (Jens K. Jensen).</para> </listitem> <listitem><para> A1200 with &blzppc; &cpu603;@160MHz (Jouko Pynnonen).</para> </listitem> <listitem><para> A1200 with &blzppc; &cpu603;@200/210MHz (Michel Dänzer).</para> </listitem> <listitem><para> A1200 with &blzppc; &cpu603;@240MHz (Alan Buxey, Sven Luther).</para> </listitem> <listitem><para> A3000T with &cybppc; &cpu604;@233MHz (Francisco Sepulveda).</para> </listitem> </itemizedlist> <para> Device Drivers:</para> <itemizedlist> <listitem><para> DISPLAY : AGA display. (Jesper Skov)</para> </listitem> <listitem><para> DISPLAY : CyberVision(/3D). (Sven Ottemann/Jimmy)</para> </listitem> <listitem><para> DISPLAY : Picasso II Clgen. (Francisco Sepulveda)</para> </listitem> <listitem><para> DISPLAY : PM2 (Ilario Nardinocchi) <footnote> <para> The driver included in the precompiled kernel is an old beta. If you want the up-to-date version get the latest sources from the PM webpage (see <xref linkend="links">). Don't expect the precompiled version to behave as described on the webpage!</para> </footnote> </para> </listitem> <listitem><para> FLOPPY : &amiga; floppy disk controller. (Sven Ottemann)</para> </listitem> <listitem><para> IDE : A4000 IDE controller. (Jesper Skov)</para> </listitem> <listitem><para> I/O : &amiga; serial. (Jesper Skov).</para> </listitem> <listitem><para> I/O : &amiga; printer. (Bartek Kozakiewicz)</para> </listitem> <listitem><para> I/O : &gvp; IO extender<footnote> <para> On some machines, the IO extender may cause the kernel to hang at startup. A crude hack can be used to work around this problem - ask on the mailing list for details if necessary.</para> </footnote> (Ken Tyler)</para> </listitem> <listitem><para> NET : A2065. (Jesper Skov)</para> </listitem> <listitem><para> NET : Ariadne. (Thomas Lohmann)</para> </listitem> <listitem><para> NET : Ariadne II. <footnote id="ariadne2"> <para>There's a performance problem with the driver. It runs at 10% of the speed compared with the &ados; driver.</para> </footnote> (Martin Koenig)</para> </listitem> <listitem><para> NET : Hydra. (Francisco Sepulveda)</para> </listitem> <listitem><para> NET : SurfSquirrel. (Carlos Mayo)</para> </listitem> <listitem><para> SCSI : A3000/T SCSI controller. (Thomas Haller/Arno Griffioen)</para> </listitem> <listitem><para> SCSI : GVP 11 SCSI controller. (Alex Kazik)</para> </listitem> <listitem><para> SCSI : GVP A2000-HC+8 Series II. (Thomas Lohmann)</para> </listitem> <listitem><para> SCSI : Oktagon 2008 SCSI. (Carsten Pluntke)</para> </listitem> <listitem><para> SCSI : A4091/4000T SCSI controller. <footnote id="a4000tscsi2"> <para>You have to disable the use of BATs to map main memory. Add <option>"nobats"</option> to your kernel options. There are still some stability problems with this driver under &linapus;.</para> </footnote> (Ken Tyler)</para> </listitem> <listitem><para> SCSI : Blizzard/PPC SCSI controller.<footnote id="blzscsi2"> <para>You have to disable the use of BATs to map main memory. Add <option>"nobats"</option> to your kernel options.</para> </footnote> (Sven Luther)</para> </listitem> <listitem><para> SOUND : &amiga; DMA sound. (Carsten Plunkte)</para> </listitem> </itemizedlist> <para>Software Drivers:</para> <itemizedlist> <listitem><para> FS : affs (Jesper Skov).</para> </listitem> <listitem><para> FS : dos (Sven Ottemann).</para> </listitem> <listitem><para> FS : ext2 (Jesper Skov).</para> </listitem> <listitem><para> FS : hfs (Bartek Kozakiewicz).</para> </listitem> <listitem><para> FS : iso9660 (Bartek Kozakiewicz).</para> </listitem> <listitem><para> FS : joliet (Bartek Kozakiewicz).</para> </listitem> <listitem><para> FS : minix (Jesper Skov).</para> </listitem> <listitem><para> FS : proc (Jesper Skov).</para> </listitem> <listitem><para> FS : vfat (Sven Ottemann).</para> </listitem> <listitem><para> MISC : z2ram (Jesper Skov).</para> </listitem> <listitem><para> RAM : ram disk (initrd) (Jesper Skov).</para> </listitem> <listitem><para> PROTOCOLS: PPP (Carsten Pluntke).</para> </listitem> </itemizedlist> </chapter> <chapter id="problems"><title>Known Problems</title> <para>There are still plenty of problems with &linapus;. Remember it is a developer kernel, so you cannot expect everything (or anything) to be working. It should get better as time goes by, though.</para> <para>The To Do list below is basically the list of known problems. If you have anything to add to the list, or if any of the listed devices are working for you, please let me know.</para> <sect1 id="todo-kernel"><title>To Do - Kernel</title> <para>I work on things as my time permits. I have had bad experiences (plural!) with fixing drivers for devices I don't have myself - it takes too much time and energy, even when someone owning such a device offers to run test kernels. Thus, if you want to see a working driver for your hardware, you really need to start hacking yourself.</para> <para>This is a list of jobs that are up for grabs. If you want to do it and you think it will take more than a couple of days, please let me know so I can mark it to prevent duplicated efforts.</para> <itemizedlist> <listitem><para> (<emphasis>free</emphasis>) If the &ados; ROM is shadowed, it will eat 512kB RAM. It <emphasis>might</emphasis> be possible to disable this shadow mapping, but I don't feel like hacking on it myself - it can be disabled manually in the Early Startup Menu.</para> </listitem> <listitem><para> (<emphasis> Roman Zippel</emphasis>) Merging the &amiboot; changes. We need someone to maintain the &amiboot; program as Geert Uytterhoeven does not have the time anymore. Presently I have put the &linapus; required changes in <xref linkend="sd-boothack">.</para> </listitem> <listitem><para> (<emphasis>free</emphasis>) A4000T/A4091 SCSI drivers require the kernel to be compiled using segment registers for memory mapping.</para> <para>Page translations are cached in on-chip translation lookaside buffers (TLBs). When a memory access is attempted and the page information is not found in the TLBs, a table lookup from main memory is required.</para> <para> When the kernel is mapped with BATs, execution of kernel code does not require looking up information about individual pages as the entire kernel memory space is mapped in one chunk.</para> <para> As the kernel memory space used to hold the NCR53c7xx SCSI scripts needs to be mapped as write-through rather than write-back, per-page cache control is required. The current kernel memory system does not mix BAT mappings with segment register mappings, so kernels compiled after 980820 have to use segment register mappings only to ensure that A4091/A4000T drivers work correctly.</para> <para>Two things can be done about this; in the short term, users who use the affected SCSI drivers must use the 'nobats' boot option.</para> <para> A proper long term solution for all users is kernel support for a mixed mapping strategy. Either by mapping the end of kernel space with segment registers and having a special allocator to deal with it, or by re-mapping the required pages with segment registers. The latter strategy is in my opinion better as any overhead will only affect the pages used for the SCSI driver scripts. Unfortunately it will require (minor) driver changes. The former will affect the entire region of memory mapped with segment registers (which will be 1/4 of the available memory - 8-16MB on most systems).</para> <para>I would like to work on this after the machine dependencies have been cleaned up in &linux; 2.3, but I see no reason to spend energy on it in the immediate future (since the drivers are working when using the 'nobats' option).</para> </listitem> </itemizedlist> <para>Other issues:</para> <itemizedlist> <listitem><para><emphasis>Complete driver for the &cybppc; onboard wide SCSI controller.</emphasis></para> <para>Jes Sørensen is working on this.</para> </listitem> <listitem><para><emphasis>Complete integration in the &linppc; source tree.</emphasis></para> <para>Recompiling a &linapus; kernel will require special patches for a long time to come. &linapus; relies on files from both the <filename class=directory>arch/m68k</filename> and <filename class=directory>arch/ppc</filename> directories which makes a clean merge with the main source tree problematic at best. There is hope though; since &linapus; is not the only port with this problem (sparc/ultrasparc, mac/powermac) there has been discussions of introducing a new "mach" hierarchy where sources specific to a given machine (such as the &amiga;) can reside.</para> <para> I will continue upgrading the patches to the latest release kernels and work on integrating changes in both <filename class=directory>arch/m68k</filename> and <filename class=directory>ppc/arch</filename>. Jes will probably be doing a lot of editing when it gets to the time of implementing the mach hierarchy.</para> </listitem> <listitem><para><emphasis>Completing the LILO port.</emphasis></para> <para>Roman Zippel is working on LILO support for &linapus;.</para> </listitem> </itemizedlist> </sect1> <sect1 id="todo-doc"><title>To Do - &thisdoc;</title> <para> There have been a few suggestions for improving &thisdoc; which require more time than I have at the moment - or I simply don't think it's worth the effort.</para> <para> If you want to write a section please do so in SGML (have a look in <filename>faq.sgml</filename> to get an idea of what is required). If you can't be bothered to do that, just send plain text and I will set it up in SGML. <emphasis>Do not send me HTML!</emphasis></para> <para> Again, if you think writing a section will stretch over a couple of days, please let me know so I can fill in your name and prevent wasted effort.</para> <itemizedlist> <listitem><para> (<emphasis>free</emphasis>) A section with boothack example configurations. (suggested by Christophe Decanini)</para> </listitem> <listitem><para> (<emphasis>free</emphasis>) A section with example memory files - I already put in the section but it's empty as no one returned my request for configurations... These might come in handy again since the kernel will eventually support both BAT and SEG mapped memory (since BATs are more efficient).</para> <para> This section should also describe how the memory system works on APUS (shadow mapping, missing 512KB, etc) - this should make it clear why memory files are (well, have) been required. Also how to properly calculate the values of a memory file.</para> </listitem> </itemizedlist> <para> Also, more generally, it's important to keep &thisdoc; up-do-date. Here are some areas that need special attention. Please send corrections, or (at least) notify the list about problems.</para> <itemizedlist> <listitem><para>Introduction. First step from ADOS to Linux.</para> </listitem> <listitem><para>Startup instructions.</para> </listitem> <listitem><para>&rh; installation instructions.</para> </listitem> <listitem><para>&debian; installation instructions.</para> </listitem> <listitem><para>File and resource links.</para> </listitem> <listitem><para>Lists of working/broken hardware/drivers.</para> </listitem> <listitem><para>Display options, X startup.</para> </listitem> </itemizedlist> </sect1> </chapter> <chapter id="help"><title>Reporting Problems/Getting Help</title> <para>There are three "official" ways of reporting problems and getting help. There may exist other news groups or mailing lists dedicated to &cybppc;, &blzppc; and/or &linux;(/APUS) than the ones described in this section. Don't expect any of the developers to read those - reporting problems by any other media than those described in this section is just as likely to be successful as reporting them to your mother (my apologies to any &linapus; hacking mothers out there :)</para> <para>Before reporting a problem, please read the section about etiquette!</para> <sect1 id="etiquette"><title>Etiquette</title> <para>Mention that you run &linapus; if you are posting a generic &linux; question to the news group. Your problem may be &linapus; specific and you will help other readers realize that if you properly identify the &linux; port you are using.</para> <para>To help others help yourself, always include as much information about the problem as possible. See <xref linkend="dev-kernel-debugging">.</para> <para>Keep your postings in a positive and friendly tone and don't expect the problem to be fixed right away. What is likely to happen is that someone will suggest solutions to your problem: you may be asked to try things you have already attempted (but didn't mention - be very informative!), you may be asked to test special versions of the kernel or the application. It's not guaranteed that your problem will be solved, but with a bit of luck it will be. Above all, be patient, understanding and positive - the developers may be working on other things, helping others with their problems, trying hard to have a life, or simply be clueless about the nature of your problem.</para> <para>Do not send questions like "I cannot boot &linux; on my &amiga;. What's wrong?". You cannot expect anyone to answer such postings, especially because there's no way anyone can be helpful without first making enquiries about your system - save yourself and others the inconvenience: supply as much information as possible.</para> <para>Please don't spam the kernel list or the news group with stories about how poor you think the &linapus; support is, or how the developers lack dedication. The only thing you get out of this is a bad reputation - it doesn't make it easier for us to support devices we don't have.</para> <para>The same goes for failing applications and/or generic kernel problems; if none of the developers are using a particular feature of the kernel or application it is hard to ensure that it is working properly. Again, it's your responsibility to help.</para> <para> Please read existing documentation before posting questions. Even though some helpful person will probably answer a frequently asked question, it's impolite (<emphasis>on your part</emphasis>) to expect others to spend time helping you when you cannot be bothered to take the help people have already offered you in form of FAQs, manuals and previously answered questions. Start by looking in the directory <filename class=directory>/usr/doc/HOWTO</filename> on a &rh; machine which may contain the answers you are looking for. <emphasis>If possible, it's always a good idea to search news group and kernel list archives for a solution to your problem. See the links page (<xref linkend="links">).</emphasis></para> </sect1> <sect1 id="the-usenet-news-group"><title>The Usenet News Group</title> <para>The Usenet News Group <ulink url="news:comp.os.linux.m68k">comp.os.linux.m68k</ulink> is read by many &amiga; users who use &linux;. It's a good place to ask if you have simple questions about &linux; that are specific to the &amiga; (see below for &linapus; questions).</para> <para>You can also ask more generic questions about the use of &linux; even though you would probably be better off posting to groups with more traffic and readers. Remember, &linux; is available on many platforms - an application problem you have is likely also to be a problem for, say, an ix86 (Intel) user.</para> <para>And there are <emphasis>tons</emphasis> of help to be found in FAQs, HOWTOs and general &linux; documentation (see <xref linkend="links">). If you are new to &linux; you might even consider buying a book about &linux; usage - this is one of the things that sets &linux; apart from &ados;; there are so many users that there's commercial interest in supporting it (with books and hot-line help).</para> </sect1> <sect1 id="the-linux-apus-kernel-list"> <title>The &linapus; Kernel List</title> <para>If you have a problem that is specific to the &linapus; installation, use of specific &linapus; packages, or if you think you have found a problem with the &linapus; kernel (i.e., a driver problem or a generic kernel problem), you should mail to the &linapus; kernel mailing list.</para> <para>You should describe how to repeat the problem. It's very hard to debug something that cannot be seen. Some problems are periodic or occur at random times in different applications, which is not easy to repeat. In this case, include whatever information you have in the posting.</para> <para>You can follow the traffic on the kernel list via the news gateway at <ulink url="news://sunsite.auc.dk/sunsite.linux.apus"> news://sunsite.auc.dk/sunsite.linux.apus</ulink>. It's fast and your mail box is not overburdened. You can also join the list (send mail to <ulink url="mailto:linux-apus-help@sunsite.auc.dk"> linux-apus-help@sunsite.auc.dk</ulink>).</para> <para>You can post to the list at the address <ulink url="mailto:linux-apus@sunsite.auc.dk"> linux-apus@sunsite.auc.dk</ulink>.</para> </sect1> <sect1 id="the-linux-apus-faq-contribution-email"> <title>The &linapus; <emphasis>FAQ Contribution</emphasis> Email Address</title> <para>This is <emphasis>not</emphasis> the place to ask for help. This address's usage should be restricted to sending the maintainer FAQ submissions. Everything else should be posted to the kernel list which has a wider audience.</para> <para>At the &linm68k; domain &linapus; has kindly been given an email alias <ulink url="mailto:apus@linux-m68k.org">apus@linux-m68k.org</ulink>. This will forward mails to whoever is maintaining &thisdoc; (at the moment me, Jesper Skov).</para> </sect1> </chapter> <chapter id="chap-faq"><title>Frequently Asked Questions</title> <para>In this chapter you will find a list of frequently asked questions. If you don't find the answer to your question, please read <xref linkend="help">.</para> <sect1 id="faq-general"><title>General Questions</title> <orderedlist> <listitem><para><emphasis>How come my questions are not answered?</emphasis></para> <para> Perhaps nobody knows the answer, or the question is not directly related to &linapus;. If the same problem is reproducible under &linm68k; you would be better of asking in a &linm68k; forum. If you don't experience the problem under &linm68k; it is likely to be &linapus; specific; please include this information when you post to the &linapus; kernel list. Even though this doesn't improve the chances of getting the problem fixed, the problem can be mentioned in &thisdoc; so others will be aware of it.</para> <para>Your question could already be answered somewhere in &thisdoc; and nobody can be bothered to tell you this. Help yourself; read the entire document - it is not that big. It is also a good idea to search for the answer to your question in the &linapus; kernel list archive.</para> <para> If you find answers to your questions in unexpected parts of this document or in the kernel list archive, please let me know so I can update &thisdoc; for the benefit of the next user with the same problem.</para> </listitem> <listitem><para><emphasis>Are there any &ados; requirements?</emphasis></para> <para> Yes. Even though the &linux; kernel in itself does not use &ados;, booting the kernel relies on &p5;'s &cpuppc; micro kernel.</para> </listitem> <listitem><para><emphasis>Is &linapus; binary compatible with the other &cpuppc; &linux; ports?</emphasis></para> <para> Yes. You can (AFAIK) use most software packages precompiled for &linppc;. Some noteworthy exceptions are: the X server (see below) and &amiga; or &linapus; specific tools which you are not likely to find available from normal &linppc; sites.</para> </listitem> <listitem><para><emphasis>How come not all &linm68k; supported devices can be selected when configuring?</emphasis></para> <para> Because &linux; configuring at the moment is architecture dependent. You have to move items from <filename>arch/m68k/config.in</filename> into <filename>arch/ppc/config.in</filename> or (even better) into the <filename>Config.in</filename> in a driver directory. If you do, please post the diff on the kernel list.</para> </listitem> <listitem><para><emphasis>Are &cybppc; developer boards supported?</emphasis></para> <para> Not at the moment - and they are not likely to be supported any time soon; moving the &cpum68k; CPU from one board to another is hell and I <emphasis>hate</emphasis> fiddling with the guts of my box. But if you have such a beast, by all means, start porting - I can give you some pointers.</para> </listitem> <listitem><para><emphasis>Is Netscape available?</emphasis></para> <para> Yes. And it's even working (according to Jens Kristian Jensen).</para> </listitem> <listitem><para><emphasis>Is the &cpum68k; CPU used for anything?</emphasis></para> <para> No. It is put to sleep (stop #2700) during boot. This may change sometime in the future. I guess it could be used as a gfx coprocessor, for clearing empty pages, or even for running native &cpum68k; programs under special conditions (like AROS).</para> </listitem> <listitem><para><emphasis>Will it ever be possible to use a mixed set of &cpum68k; and &cpuppc; executables?</emphasis></para> <para> Not likely. This would require a shared memory mapping. However, nothing is impossible - you go ahead!</para> </listitem> <listitem><para><emphasis>I can't boot from the ram disk with 2.1.90 kernels!?!</emphasis></para> <para> There's some problem with identifying MINIX headers in 2.1.90. Use gzip to compress the ram disk and it will work.</para> </listitem> <listitem><para><emphasis>Does &linapus; support kernel debugging with &gdb;?</emphasis></para> <para> The kernel <emphasis>diff</emphasis> contains the necessary stubs and config flag (<symbol>CONFIG_KGDB</symbol>) to do this (originally for PMAC, written by Mike Tesch). A debug kernel is around 10MB though so I will not upload a precompiled kernel with debugging. I have still not tested this so your mileage may vary.</para> </listitem> <listitem><para><emphasis>When I recompile the kernel using your patches, I get disk failures and runtime errors!?!</emphasis></para> <para> Use binutils-2.9.1 and egcs-1.1. Get the 980525 kernel sources or newer and you should be OK.</para> </listitem> <listitem><para><emphasis>Why not use LPSTOP to halt the CPU on &cpu060; systems?</emphasis></para> <para> It hangs the system. Possibly because the &cybppc; bus design cannot cope with the signals the &cpu060; sends out before powering down.</para> </listitem> <listitem><para><emphasis>I cannot mount all my partitions. There are not enough dev nodes in the ram disk!?!</emphasis></para> <para> I have put <application>mknod</application> compiled for &cpuppc; in <xref linkend="sd-misc">. Put it on an &ados; partition you can mount, boot the kernel, mount the &ados; partition, use <application>mknod</application> to make new nodes.</para> </listitem> <listitem><para><emphasis>My system just hangs when I start &boothack;!??</emphasis></para> <para> It might be a problem with &boothack;. Try rebooting the machine and run the tool <application>bootmesg</application>. It should find a progress string from the booter. This string is deleted by the kernel if it boots, so if the string is not found, it's probably a kernel problem (and you should use <option>debug=mem</option> and &dmesg; instead).</para> <para> The last character stored before jumping to the kernel is 'K'. If you see a string, and the last letter is not 'K', you can look in the <filename>ppc_boot.c</filename> code to get an idea of where things go wrong. Please also report your findings.</para> <para> Another thing that is likely to cause this problem is memory. See <xref linkend="booting-linux-apus"> for some more information on this point.</para> <para> Yet another common cause is wrong video mode parameters. <option>'vga'</option> has caused problems, while specifying none (if your monitor can handle it) definitely works. If you have a CyberVision you have to let it be initialized by CyberGfx before you boot.</para> <para> You must also disable Shadow ROM in the &cybppc; or &blzppc; Early Startup Menu and set the memory speed to 70ns.</para> <para> Finally, make sure to put &boothack; options (starts with a dash (-)) first on the line and kernel options (no dash) last on the line when booting the kernel.</para> </listitem> <listitem><para><emphasis>Can I boot from a soft kicked system?</emphasis></para> <para> Possibly. You might be able to make it work. Do try it. If it doesn't work you have to disable the soft kicked ROM. You might also try booting your machine without <filename>startup-sequence</filename>, run <application>setpatch</application> and then start &linapus; (unless you have a CyberVision in which case you must let CyberGfx initialize it first).</para> </listitem> <listitem><para><emphasis>Can I compile my own kernels under &linapus;?</emphasis></para> <para> Yes. I have successfully run a kernel I build with binutils-2.9.1 and egcs-1.1 on my &linapus; box. However, YMMV.</para> </listitem> <listitem><para><emphasis>I get rejects when applying your patch!!??</emphasis></para> <para> My patches are relative to the <emphasis>release</emphasis> versions of the &linm68k; kernel sources (not Linus' kernel sources!). If you apply &linm68k; patches from the &linm68k; kernel list before you apply my patches, you may get conflicts.</para> </listitem> <listitem><para><emphasis>I cannot boot &linapus; on my &blzppc;!!?</emphasis></para> <para><emphasis>Hint from Sinan Gurkan</emphasis></para> <para> The later firmware versions make the hardware identify itself as if it had a SCSI controller - even the boards with no SCSI controller! Until the problem gets properly fixed, you can press <keycap>s</keycap> during boot to disable the (non-existing) SCSI hardware :)</para> </listitem> <listitem><para> <emphasis>How do I boot with AGA display on a machine with CyberVision(/3D)?</emphasis></para> <para>You need to disable the frame buffer device assigned to the graphics card by adding (one of) the below to the boot options.</para> <screen> video=cyber:off video=virge:off</screen> </listitem> <listitem><para> <emphasis> How do I change the default keymap?</emphasis></para> <para><emphasis>Text by Marco De Vitis</emphasis></para> <para> Let's assume you already have a keymap file that suits your system, e.g. <filename>amiga-it.map</filename> for an Italian Amiga keyboard (you can find many keymap files at <ulink url="ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/"> ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/</ulink>). Put this file in the <filename class="directory">/usr/lib/kbd/keytables</filename> directory. You should now be able to load it by issuing this command:</para> <screen> loadkeys amiga-it.map </screen> <para> To have it loaded during boot (on &rhppc;), you have to edit the <filename>/etc/sysconfig/keyboard</filename> file so that it contains the full path to your keymap; by default, it should read something like "/usr/lib/kbd/keytables/amiga-us.map", so you usually only need to change the ending.</para> </listitem> <listitem><para> <emphasis> How come the sound driver is not included in the prebuilt kernels?</emphasis></para> <para> Because it doesn't like the heartbeat (which affects the filter when blinking the led). Heartbeat is important for determining if &linapus; has properly booted even if the display is blank, i.e., it is relevant in a kernel that a novice will boot for the first time. And it means I don't have to switch display each time I boot a kernel ;)</para> <para> If you worry about sound support, it means you have a stable system -- and that means that you should be able to rebuild the kernel yourself.</para> </listitem> <listitem><para> <emphasis> Why can't the mailing list...?</emphasis></para> <para> It's not by accident that the list server is set up as it is -- this is the way the guys in power like it :) See below for some workarounds.</para> <para> SUBJECT LINE: If you want [APUS] or similar in the subject line, it's probably because you want to sort/filter your mail by subject. In that case, your mailer should be able to sort/filter by any other header line. A good one is:</para> <screen> Mailing-List: contact linux-apus-help@sunsite.auc.dk; run by ezmlm </screen> <para> REPLY-TO: Yes, you 'reply' to the author of the article. We are all real living people -- if you want to reply to something it's because you want to say something to the dude at the other end of the damp string, no? :) Polite people mostly CC: the list so others can benefit from the reply as well. So, use 'followup' instead of 'reply'. Yes, the receiver gets two copies; that is The-Way-It-Should-Be(TM).</para> </listitem> <listitem><para><emphasis> Where can i find information about the unix command line syntax?</emphasis></para> <para> There are a lot of HOWTO's available at the Linux Documentation Project, available at : <ulink url="http://metalab.unc.edu/LDP/"> http://metalab.unc.edu/LDP/</ulink>. One in particular is useful for first timer, altough it is more oriented to msdos upgraders, it is the "DOS/Win to Linux HOWTO", available at : <ulink url="http://metalab.unc.edu/LDP/HOWTO/DOS-Win-to-Linux-HOWTO.html"> http://metalab.unc.edu/LDP/HOWTO/DOS-Win-to-Linux-HOWTO.html</ulink> Notice : these howtos can be found in the following debian packages : <filename>doc/doc-linux-text_xxx.deb</filename> for the text version <filename>doc/doc-linux-html_xxx.deb</filename> for the html version. There are also lots of translation packages : <filename>doc/doc-linux-fr_xxx.deb</filename> for example for the french version. </para> </listitem> </orderedlist> </sect1> <sect1 id="faq-redhat"><title>&rhppc; Related Questions</title> <orderedlist> <listitem><para> <emphasis> X isn't working right </emphasis></para> <para> The linuxppc X packages (unlike &debian;) install only a Pmac X server (XPmac), just get the one from Geert's site, and copy it in <filename class="directory">/usr/X11R6/bin</filename>, and change the X symlink with : </para> <screen> prompt> rm X prompt> ln -s XF68_FBDev X </screen> <para> Also see <xref linkend="x">. </para> </listitem> <listitem><para> <emphasis> The console is flashing </emphasis></para> <para>See <xref linkend="install-problems">.</para> </listitem> </orderedlist> </sect1> <sect1 id="faq-debian"><title>&debian; Related Questions</title> <orderedlist> <listitem><para><emphasis> How to get an pm2 accelerated X server for &debian;?</emphasis></para> <para>get the XF68_FBDev_pm2_4 or later file from <ulink url="http://dpt-info.u-strasbg.fr/~luther/xfree/"> http://dpt-info.u-strasbg.fr/~luther/xfree/</ulink> and copy it to your <filename class="directory">/usr/X11R6/bin</filename> directory. Check the readme files on the web site to see what each of those XF68_FBdev_pm2 files contain. Then you need to edit <filename>/etc/X11/Xserver</filename>, and change the first line to be the absolute path to the Xserver (should be <filename>/usr/X11R6/bin/XF68_FBDev_pm2_4</filename> in our case, but you can put it anywhere you want, or rename it to your liking). There are various Xserver in the above dir, some contains GC acceleration, very fast but still some graphical problems, other have GC acceleration disabled. It is up to you to choose which one you want. Read the readme file to check. Notice : this patch will be in the nect release of Xfree 3.3.4, so you will not need to do this then. </para> </listitem> </orderedlist> </sect1> </chapter> <chapter id="history"><title>History</title> <para>I like to follow the progress of the stuff I use, so I decided to keep track of &linapus; changes so others with the same interest can get an idea of what's happening.</para> <para>I also keep source code ChangeLogs (<ulink url="ChangeLog-22x.APUS">ChangeLog-22x</ulink> and <ulink url="ChangeLog-23x.APUS">ChangeLog-23x</ulink>) for the &linapus; changes which are available from <xref linkend="sd-docs">.</para> <para> Please note that some of the entries may only apply to one of the kernel trees. If in doubt, check the 22x and 23x ChangeLogs for details.</para> <para> <emphasis>date990821 990821</emphasis> <itemizedlist> <listitem><para>Added link to R5 installation guide.</para> </listitem <listitem><para>Updated stable and developer sources.</para> </listitem> </itemizedlist> <emphasis> 990703</emphasis> <itemizedlist> <listitem><para>Updated the FAQ with text from Sven Luther and Douglas Valentine.</para> </listitem> <listitem><para>More hypercom updates from Gordon Huby.</para> </listitem> <listitem><para>Sound and heartbeat patch from Chris Lawrence</para> </listitem> </itemizedlist> <emphasis> 990605</emphasis> <itemizedlist> <listitem><para>Added A1200 HyperCOM1 serial driver from Gordon Huby.</para> </listitem> </itemizedlist> <emphasis> 990602</emphasis> <itemizedlist> <listitem><para>Added keyboard fix from Jeff Crystal/Geert Uytterhoeven.</para> </listitem> </itemizedlist> <emphasis> 990530</emphasis> <itemizedlist> <listitem><para>Fixed some broken APUS links (thanks Douglas).</para> </listitem> <listitem><para>Re-organized this document a bit.</para> </listitem> <listitem><para>Made a new stable branch. </para> </listitem> </itemizedlist> <emphasis> 990523</emphasis> <itemizedlist> <listitem><para>Added a new paragraph about kernel sources/diffs. (suggested by Douglas Valentine)</para> </listitem> <listitem><para>Added a new FAQ entry from Sven Luther.</para> </listitem> </itemizedlist> <emphasis>990516</emphasis> <itemizedlist> <listitem><para>Source release only - serious changes and known keyboard problem.</para> </listitem> <listitem><para>Updated to &linm68k; 2.2.8.</para> </listitem> <listitem><para>Merged in a few vger changes. apus_setup.c needs a major overhaul, but now the framework is there to do a proper job of it...</para> </listitem> <listitem><para>Applied fixes from Chris Lawrence and Jouko Pynnonen.</para> </listitem> </itemizedlist> <emphasis>990504</emphasis> <itemizedlist> <listitem><para>Fixed a few broken links (thanks, Geert).</para> </listitem> <listitem><para>Added some stuff to <filename>/proc/cpuinfo</filename> so an &linapus; system can be recognized by the installer.</para> </listitem> </itemizedlist> <emphasis> 990502</emphasis> <itemizedlist> <listitem><para>Added new section about X and CyberGfx stuff from Jeff Crystal.</para> </listitem> </itemizedlist> <emphasis> 990421</emphasis> <itemizedlist> <listitem><para>Added __lshrdi3 patch from Gabriel Paubert (paubert@iram.es) (from ppc kernel list).</para> </listitem> <listitem><para>Added mb() to ser_ioext in an attemt to work around a problem found by Peter Kaltstein (CyberStrike@studbox.uni-stuttgart.de).</para> </listitem> </itemizedlist> <emphasis> 990403</emphasis> <itemizedlist> <listitem><para>Named the files of this document so you can now add bookmarks that will work.</para> </listitem> <listitem><para>Added the PCMCIA WHIPPET & APNE drivers. Mecha Ike deserves credits for almost beating me to it :)</para> </listitem> </itemizedlist> <emphasis> 990323</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.3pre1.</para> </listitem> </itemizedlist> <emphasis> 990322</emphasis> <itemizedlist> <listitem><para>Added mb() fix for A2091 driver from Jes.</para> </listitem> </itemizedlist> <emphasis> 990321</emphasis> <itemizedlist> <listitem><para>Added yet another info item for GPM, this time from Gerard Cornu.</para> </listitem> <listitem><para>ChangeLog now available from this document. Incremental change logs included in the <filename>linux-apus-YYMMDD.diff</filename> diffs as a comment.</para> </listitem> </itemizedlist> <emphasis> 990301</emphasis> <itemizedlist> <listitem><para>Ken Tyler sends me a virge blitter fix as a birthday present ;)</para></listitem> </itemizedlist> <emphasis> 990221</emphasis> <itemizedlist> <listitem><para>Arno Griffioen takes matters in his own hands and fixes DMA on the A3000 SCSI controller :)</para> </listitem> <listitem><para>I added the same DMA patches to the A2091 and GVP11 drivers.</para> </listitem> </itemizedlist> <emphasis> 990220</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.1pre2.</para> </listitem> <listitem><para>Cleaned up serial driver and GDB support.</para> </listitem> </itemizedlist> <emphasis> 990214</emphasis> <itemizedlist> <listitem><para>Added <application>gpm</application> note from Robert Ramiega.</para></listitem> </itemizedlist> <emphasis> 990206</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.1pre1.</para> </listitem> <listitem><para>Removed parallel/printer drivers. The new driver scheme seems to hang the kernel and I don't have the time to track it down now.</para> </listitem> </itemizedlist> <emphasis> 990203</emphasis> <itemizedlist> <listitem><para>Updated &thisdoc; to compile with DocBook 3.0</para></listitem> </itemizedlist> <emphasis> 990201</emphasis> <itemizedlist> <listitem><para>Debian install help updated (Michel Dänzer)</para> </listitem> <listitem><para>Added Virge Z2 support from (Christian T. Steigies).</para> </listitem> </itemizedlist> <emphasis> 990131</emphasis> <itemizedlist> <listitem><para>NO_RELOAD_TAB fix from Michel Dänzer.</para> </listitem> <listitem><para>Cleaned up APUS: output during boot.</para> </listitem> </itemizedlist> <emphasis>990129</emphasis> <itemizedlist> <listitem><para>Virge update from Ken Tyler.</para> </listitem> <listitem><para>Other video updates from Geert Uytterhoeven.</para> </listitem> </itemizedlist> <emphasis> 990123</emphasis> <itemizedlist> <listitem><para>Module fix from Andreas Schwab.</para> </listitem> <listitem><para>Menuconfig and module fix from Michel Dänzer).</para> </listitem> <listitem><para>Rewrote part of the interrupt handling. Lvl7 interrupts cannot be avoided, but they are now treated as the bogus Lvl0 interrupts.</para> </listitem> </itemizedlist> <emphasis> 990118</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.0pre7.</para> </listitem> <listitem><para>Replaced the obsolete cvppc driver with the pm2 driver (Ilario Nardinocchi).</para> </listitem> <listitem><para>Fix BlizzardPPC SCSI's dependencies (Michel Dänzer).</para> </listitem> <listitem><para>Replaced iobarrier() with mb().</para> </listitem> </itemizedlist> <emphasis> 990113</emphasis> <itemizedlist> <listitem><para>Added fix for building lp as module from Frank Petzold.</para> </listitem> <listitem><para>Removed FastLane from list of working hardware and from the precompiled kernels.</para> </listitem> </itemizedlist> <emphasis>990112</emphasis> <itemizedlist> <listitem><para>Added &debian; installation section by Michel Dänzer.</para> </listitem> </itemizedlist> <emphasis> 990111</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.0pre6. There might be problems with memory mapping devices. If you experience problems, try using the nobats option.</para> </listitem> </itemizedlist> <emphasis> 990106</emphasis> <itemizedlist> <listitem><para>Added PowerUp PCI Bridge detection to boothack. Contributed by Ralph Schmidt.</para> </listitem> </itemizedlist> <emphasis> 990105</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.2.0pre4. Light my fire, baby! It's smoooking fast :@) &x; starts in no time now... I need to get this kernel installed on Concubine!</para> </listitem> <listitem><para>Changed installer directory structure on &sunsite; in preparation for proper support of &debian; installation schemes.</para> </listitem> <listitem><para>Martin Koenig sez the Ariadne II driver is working (somewhat slow though).</para> </listitem> <listitem><para>Carlos Mayo sez the SurfSquirrel is working. (PCMCIA card, right?).</para> </listitem> <listitem><para>Updated &thisdoc; here and there. If I missed anything during the past couple of weeks, please let me know.</para></listitem> </itemizedlist> <emphasis> 981216</emphasis> <itemizedlist> <listitem><para>Updated to &linm68k; 2.1.131.</para> </listitem> </itemizedlist> <emphasis> 981213</emphasis> <itemizedlist> <listitem><para>Added patch from Richard Hirst to fix CDROM mount problem on A4000T/A4091 SCSI.</para> </listitem> <listitem><para>Changed CONFIG_PPC in sound driver to CONFIG_PMAC. I'd like to know if it solves the problems.</para> </listitem> </itemizedlist> <emphasis> 981129</emphasis> <itemizedlist> <listitem><para>Added a handful of patches from Chris Lawrence.</para> </listitem> </itemizedlist> <emphasis> 981127</emphasis> <itemizedlist> <listitem><para>Updated to 2.1.130</para> </listitem> <listitem><para>Fixed off-by-1 error in reloc code. This is what stopped some people from running the later kernels, I'm sure.</para> </listitem> <listitem><para>Added a (good) handful of iobarriers to the MFC serial driver. It might have fixed the reported problem.</para> </listitem> </itemizedlist> <emphasis> 981126</emphasis> <itemizedlist> <listitem><para>The <filename class="directory">latest</filename> directory now contains files (not links) with dated names to prevent confusion in the future. If people try to download using a cached and obsolete name, they should get an error.</para> </listitem> <listitem><para>Reintroduced the <filename>head.S</filename> progress values.</para> </listitem> </itemizedlist> <emphasis> 981125</emphasis> <itemizedlist> <listitem><para>Included Whippet driver. I got a patch from Carlos Mayo some time ago, but it was already included in 2.1.127.</para> </listitem> <listitem><para>Changed a few bits of the new relocation magic per suggestion from Paul Mackerras. I can't imagine it will help on the failing boxes but one never knows.</para> </listitem> <listitem><para>Added new sections by Marco (FAQ) and Matthias (X).</para> </listitem> </itemizedlist> <emphasis> 981122</emphasis> <itemizedlist> <listitem><para>Added some &debppc; links from Sven Luther</para> </listitem> <listitem><para>Updated list of included drivers.</para> </listitem> <listitem><para>The vger integration is pretty much done now.</para> </listitem> <listitem><para>Reports of 981121 failing to boot. *sigh* If you can get it to boot, use an older kernel.</para> </listitem> </itemizedlist> <emphasis> 981121</emphasis> <itemizedlist> <listitem><para>Added X help text from Marco De Vitis.</para> </listitem> <listitem><para>Good progress on the major &linapus; workover and vger integration. It's now close to being possible to boot a &linapus; kernel on any of the other PPC targets. Do I need to point out that this is a Good Thing(TM) for distributions? :) Still a few nits to sort out though.</para> </listitem> <listitem><para>&boothack; needed a modification to allow the above changes so you need to get that as well. It is backwards compatible, so you can still use it with the older kernels.</para></listitem> <listitem><para>Included pretty much all drivers in the kernel image (and Mac FS and partition table support).</para> </listitem> </itemizedlist> <emphasis> 981117</emphasis> <itemizedlist> <listitem><para>Worked on vger integration.</para> </listitem> </itemizedlist> <emphasis> 981114</emphasis> <itemizedlist> <listitem><para>Renamed iobarrier macros.</para> </listitem> <listitem><para>Updated CyberVision driver. Might have broken it, please let me know.</para> </listitem> <listitem><para>Cleaned up links (see <xref linkend="links">).</para></listitem> </itemizedlist> <emphasis> 981112</emphasis> <itemizedlist> <listitem><para>Replaced auxmem with a simpler hack. Even though auxmem would have been pretty compared with the random hacking of Z2 and motherboard memory now used, it would also have been overkill.</para> </listitem> <listitem><para>Updated to 2.1.127.</para> </listitem> </itemizedlist> <emphasis> 981108</emphasis> <itemizedlist> <listitem><para>Added section about installing from a &rhrc; CD.</para></listitem> <listitem><para>Included Ilario's CVPPC frame buffer device. See the home page for details on use (<xref linkend="linux-links">).</para> </listitem> </itemizedlist> <emphasis> 981107</emphasis> <itemizedlist> <listitem><para>Sync'd with vger again. Mainly to get some &linapus; changes into the &linux; main tree.</para> </listitem> <listitem><para>Juiced up my motivation (nice meeting you, Ken & Julian :)</para> </listitem> <listitem><para>Fixed stupid bug in mm_ptov. Found by Ilario.</para> </listitem> <listitem><para>Redid the fb X fix, avoiding ptov calls.</para> </listitem> </itemizedlist> <emphasis> 981105</emphasis> <itemizedlist> <listitem><para>Added '60nsram' kernel option.</para> </listitem> <listitem><para>Added 'nobats' kernel option.</para> </listitem> <listitem><para>Improved memory mapping; should use BATs correctly, even on &blzppc; cards with weird alignment.</para> </listitem> </itemizedlist> <emphasis> 981103</emphasis> <itemizedlist> <listitem><para>Added patch from Peter McGavin to fix EGS.</para> </listitem> <listitem><para>Added patch from Frank Petzold to fix modules.</para> </listitem> <listitem><para>Worked a bit more on &thisdoc;</para> </listitem> </itemizedlist> <emphasis> 981102</emphasis> <itemizedlist> <listitem><para>Sync'd PPC stuff with vger.</para> </listitem> <listitem><para>Proper fix to the X problem.</para> </listitem> <listitem><para>Started rearranging &thisdoc; into two parts.</para> </listitem> </itemizedlist> <emphasis> 981031</emphasis> <itemizedlist> <listitem><para>Added IDEDOUBLER fix from Geert Uytterhoeven.</para> </listitem> <listitem><para>Added X fix from Carsten.</para> </listitem> <listitem><para>Added some installer doc changes from Ken Tyler.</para> </listitem> </itemizedlist> <emphasis>981018</emphasis> <itemizedlist> <listitem><para>Sven found the problem preventing proper operation on Blizzard. It was as suspected all along related to the new (soon obsolete :) booting process.</para> </listitem> <listitem><para>I have started using egcs-1.1 for building kernels. They seem to work fine on my box. I'd like to hear from you ASAP if they don't work on your box.</para> <para>I don't know if the patches <xref linkend="sd-misc"> are necessary for egcs-1.1. I guess time will tell. (Remember; if parts of the patch seems to be missing in egcs-1.1 it doesn't necessary mean that the problem the patch fixed in 1.0.3 hasn't been fixed in some other way.)</para> </listitem> <listitem><para>Included the serial driver again.</para> </listitem> </itemizedlist> <emphasis> 981014</emphasis> <itemizedlist> <listitem><para>Added &rh; install updates from Ken Tyler to &thisdoc;</para> </listitem> </itemizedlist> <emphasis>981009</emphasis> <itemizedlist> <listitem><para>Updated to 2.1.124 (X is still broken).</para> </listitem> </itemizedlist> <emphasis>981005</emphasis> <itemizedlist> <listitem><para>Included Fastlane SCSI driver.</para> </listitem> </itemizedlist> <emphasis>981004</emphasis> <itemizedlist> <listitem><para>Wasted some more time on KGDB. It's still not good, but it's better.</para> </listitem> <listitem><para>Added heartbeat.</para> </listitem> </itemizedlist> <emphasis>981003</emphasis> <itemizedlist> <listitem><para>Made KGDB work (still some problems to sort out, but it is usable).</para> </listitem> <listitem><para>Added workaround for ioremap bug. You can now use motherboard/Z2 memory for swap (see relevant FAQ entry).</para> </listitem> <listitem><para>Added compiler option (-fno-strength-reduce) that may (or may not) affect the A4000T/A4091 SCSI drivers.</para> </listitem> </itemizedlist> <emphasis>981002</emphasis> <itemizedlist> <listitem><para>Added some more changes to the &rh; installer sections from Ken Tyler.</para> </listitem> </itemizedlist> <emphasis> 980926</emphasis> <itemizedlist> <listitem><para>Included some changes to the &rh; installer sections from Ken Tyler.</para> </listitem> <listitem><para>Added new FAQ entry from Ken Tyler (disabling CV to boot on AGA).</para> </listitem> <listitem><para>Added new section with suggestions for &thisdoc;</para> </listitem> <listitem><para>Christophe Decanini reports that RH CDROM, FTP and NFS installation methods work.</para> </listitem> </itemizedlist> <emphasis> 980915</emphasis> <itemizedlist> <listitem><para>Added Geert Uytterhoeven's patch to allow 1024x768-16bp with CyberVision.</para> </listitem> </itemizedlist> <emphasis> 980912</emphasis> <itemizedlist> <listitem><para>Undid the first change of 980907 since it made the kernel fail to boot on most other machines.</para> </listitem> </itemizedlist> <emphasis>980908</emphasis> <itemizedlist> <listitem><para>Updated to 2.1.120.</para> </listitem> </itemizedlist> <emphasis>980907</emphasis> <itemizedlist> <listitem><para>Only 128kB is eaten by the PPC exception registers now, leaving 384kB more free memory than before.</para> </listitem> <listitem><para>Added a simple and not yet fully functional method for using motherboard memory as swap. See new FAQ entry.</para> </listitem> </itemizedlist> <emphasis>980902</emphasis> <itemizedlist> <listitem><para>Submitted patch to vger (well, to Geert, really :)</para> </listitem> <listitem><para>Added code to determine bus speed written by Ralph Schmidt.</para> </listitem> </itemizedlist> <emphasis>980901</emphasis> <itemizedlist> <listitem><para>Added latest vger PPC changes.</para> </listitem> <listitem><para>The above bloated the kernel so much that a linker/booter problem prevented it from booting. I removed the Retina and clGen graphics drivers because of this.</para> </listitem> </itemizedlist> <emphasis>980831</emphasis> <itemizedlist> <listitem><para>It's now possible to disable wait states for all bus speeds. Sven Ottemann has been pushing for this for some time, but let me warn you; you need 60ns RAM, and according to Phase5 it doesn't work on 66MHz buses. YMMV.</para> </listitem> <listitem><para> Now the bus speed ID is output at startup to help debugging.</para> </listitem> </itemizedlist> <emphasis>980830</emphasis> <itemizedlist> <listitem><para>Sven Ottemann fixed the booter to be a one-file image, rather than the old ADOSHUNK/ELF pair.</para> </listitem> <listitem><para>Made the booter clear all MMU registers. <filename>head.S</filename> now sets up all the required mappings - which makes the &blzppc; get past the old trouble spot. There are still some problems left though.</para> </listitem> <listitem><para>Reintroduced colors to &thisdoc;, marking new stuff. The chapters and sections are appended with a date where appropriate so you can see where the latest changes are from the table of contents.</para> </listitem> </itemizedlist> <emphasis> 980829</emphasis> <itemizedlist> <listitem><para>Updated to &linux; 2.1.119.</para> </listitem> </itemizedlist> <emphasis> 980827</emphasis> <itemizedlist> <listitem><para> Fixed a potential problem in <filename>head.S</filename>. &blzppc; owners should give it a try.</para> </listitem> </itemizedlist> <emphasis>980822</emphasis> <itemizedlist> <listitem><para> Ken Tyler informs me that the A4091/A4000T SCSI driver is finally working. This is due to the fabulous work of Richard Hirst. Still, this has resulted in an item on the to do list (performance penalty).</para> </listitem> <listitem><para> I have put my sources under CVS control so in the future I will be able to release incremental diffs of the &linapus; sources.</para> </listitem> </itemizedlist> <emphasis>980821</emphasis> <itemizedlist> <listitem><para> Francisco also reports that the Hydra driver is working. </para> </listitem> <listitem><para> &blzppc; owners should check the FAQ entry specific to their HW. I just added a suggestion from Sven Luther.</para> </listitem> </itemizedlist> <emphasis>980820</emphasis> <itemizedlist> <listitem><para> Francisco Sepulveda informs me that the Picasso driver is working on his A3000T.</para> </listitem> <listitem><para> Added patch to menubox.c from Frank Petzold.</para> </listitem> <listitem><para> Changed kernel to use segment registers for mapping kernel space. This might fix the A4000T/A4091 driver problem (even though I'm tired of being enthusiastic about that :)</para> </listitem> </itemizedlist> <emphasis>980816</emphasis> <itemizedlist> <listitem><para> Completed move of &thisdoc; to DocBook. That took some time!</para> <para> I wonder if anyone will miss the color highlighting of changes to the document? If so, let me know and I will get it working again.</para> </listitem> <listitem><para> Added some changes from &linppc;</para> </listitem> </itemizedlist> <emphasis>980813</emphasis> <itemizedlist> <listitem><para> Included &blzppc; SCSI driver again.</para> </listitem> <listitem><para> Included Buddha IDE driver.</para> </listitem> <listitem><para> Included patch to socket.h</para> </listitem> </itemizedlist> <emphasis>980812</emphasis> <itemizedlist> <listitem><para>Included clgen gfx driver.</para> </listitem> <listitem><para>More additions to the A4091 support.</para> </listitem> <listitem><para>Updated to linux-2.1.115</para> </listitem> </itemizedlist> <emphasis>980801</emphasis> <itemizedlist> <listitem><para> Unfortunately the new &boothack; still can't boot &linapus; properly on &blzppc; - possibly a problem with the 040. I'd like to hear from &cybppc; people who can boot on an 040.</para> </listitem> <listitem><para> Added a few syncs and eieios to the booter.</para> </listitem> <listitem><para> Added Sven's Blizzard SCSI patches. The kernel image in vmbl980801.lzh includes this driver and a not the Gayle IDE driver which conflicts with the SCSI driver for some reason.</para> </listitem> </itemizedlist> <emphasis>980730</emphasis> <itemizedlist> <listitem><para> &boothack;: Added more robust synchronization between the CPUs (the "wedgie" scheme).</para> </listitem> <listitem><para> &boothack;: Added stack space for &cpuppc; in CHIP.</para> </listitem> <listitem><para> &boothack;: Invalidate cache contents.</para> </listitem> <listitem><para> &boothack;: Disable TimerBase interrupts (this is the one that won the gold).</para> </listitem> <listitem><para> The above ensures rock-stable booting on my box with the 980711 ppc.library. No more bad checksums; it's just awesome :)</para> </listitem> </itemizedlist> <emphasis>980726-2</emphasis> <itemizedlist> <listitem><para> Updated my ppc.library to 980711. I now know what the problem has been on the &blzppc; cards - I think :)</para> </listitem> <listitem><para> Moved head.S progress word to 0xfff0eff0.</para> </listitem> <listitem><para> Added some text about how to avoid memory problems when booting (Please <emphasis>do</emphasis> read it and tell me if it is of any help, or if it requires changes/additions).</para> </listitem> <listitem><para> Added checksum code to the booter.</para> </listitem> </itemizedlist> <emphasis>980726</emphasis> <itemizedlist> <listitem><para> Fixed the problem with zorro devices count.</para> </listitem> <listitem><para> Fixed memory initialization code again.</para> </listitem> </itemizedlist> <emphasis>980725</emphasis> <itemizedlist> <listitem><para> Fixed silly bug in an A4091/A4000T SCSI driver support routine which caused kernel panics.</para> </listitem> <listitem><para> Thomas Lohmann informs me that Ken&Son's &rhinstaller; works with FTP.</para> </listitem> <listitem><para> Added new contrib directory at &sunsite; (see <xref linkend="sunsite">).</para> </listitem> <listitem><para> Memory initialization should now correctly identify an active &ados; ROM shadow and ignore that 512kB block of memory.</para> </listitem> </itemizedlist> <emphasis>980724</emphasis> <itemizedlist> <listitem><para> Changed date format to YYMMDD.</para> </listitem> <listitem><para> Fixed problem with Zorro structures (get newest &boothack;).</para> </listitem> </itemizedlist> <emphasis>980723</emphasis> <itemizedlist> <listitem><para> Apparently lots of stuff is broken in 2.1.108: CyberVision, GVP HC+8, you name it. I'm clueless. Nothing really changed on the &linapus; side of things, so I must have missed some serious &linm68k; changes.</para> </listitem> <listitem><para> Thomas Lohmann informs me that CV works with the console in all resolutions after he installed the ppc.library included in cybergfx of 05.07.98 (IIRC).</para> </listitem> <listitem><para> I tried including sound in the kernel, but there is a build problem.</para> </listitem> <listitem><para> I have made some changes to the A4091/A4000T driver support that might make a difference.</para> </listitem> </itemizedlist> <emphasis>980719</emphasis> <itemizedlist> <listitem><para> Added Richard Hirst's 53c710 patch.</para> </listitem> </itemizedlist> <emphasis>980711</emphasis> <itemizedlist> <listitem><para> Moved patches to 2.1.108.</para> </listitem> <listitem><para> Added a few FAQ changes suggested by Thomas Lohmann. He also told me that the GVP A2000-HC+8 Series II SCSI controller is working with &linapus;.</para> </listitem> </itemizedlist> <emphasis>980710</emphasis> <itemizedlist> <listitem><para> Increased SCSI timeouts.</para> </listitem> <listitem><para> Tested &linapus; startup with ppc.library version 46.15 and 68060.library version 44.3. No problems whatsoever on my box.</para> </listitem> </itemizedlist> <emphasis>980707</emphasis> <itemizedlist> <listitem><para> Massimo Gais has made a mirror of the apus directory at ftp.unina.it.</para> </listitem> </itemizedlist> <emphasis>980617</emphasis> <itemizedlist> <listitem><para> Reordered the sections in the installation chapter.</para> </listitem> <listitem><para> Changed the booter to disable ROM mappings. Maybe it will help on &blzppc; cards?</para> </listitem> </itemizedlist> <emphasis>980616</emphasis> <itemizedlist> <listitem><para> I have run of ideas for what could be causing the &blzppc; problem. Someone with a &blzppc;s needs to dig in and have a look. I'm not spending any more time on this....</para> </listitem> <listitem><para> Ken and Julian Tyler have completed the &rhinstaller; support for &linapus;. Obviously this makes it <emphasis>much</emphasis> easier to get a system properly installed and working.</para> </listitem> </itemizedlist> <emphasis>980615</emphasis> <itemizedlist> <listitem><para> &sunsite; has been unaccessible for a couple of days now. It's due to a cut cable on the Danish back bone (I think).</para> </listitem> <listitem><para> Bartek Kozakiewicz tells me that HFS and ISO9660/Joliet drivers are working. And also that the printer driver is working.</para> </listitem> </itemizedlist> <emphasis>980612</emphasis> <itemizedlist> <listitem><para> Now writes head.S progress to 0xfff07000. Hope it works this time... *sigh*</para> </listitem> <listitem><para> Cleaned up &linapus; changes to intrude less on the &linm68k; sources.</para> </listitem> </itemizedlist> <emphasis>980610</emphasis> <itemizedlist> <listitem><para> Carsten Plunkte tells me it is important to apply the egcs patches from &sunsite; if building applications (I added a new subsection to Applications).</para> </listitem> </itemizedlist> <emphasis>980609</emphasis> <itemizedlist> <listitem><para> Moved patches to 2.1.105.</para></listitem> <listitem><para> Geert Uytterhoeven tells me that emacs-nox also fails on CHRP so it is indeed an application problem.</para> </listitem> </itemizedlist> <emphasis>980607</emphasis> <itemizedlist> <listitem><para> Updated ppc.library to V45.20. Everything is still working. Also tried installing another 8MB but the ppc.library (V44.27) wouldn't run then. I might try installing the RAM again with the new ppc.library at some time.</para> </listitem> <listitem><para> Corrected initial mapping in head.S - I had set it to 4MB, not 8MB.</para> </listitem> <listitem><para> Now writes head.S progress to address 0xfff02ffc which exists on all PoweUp boards and is not deleted by the &p5; &cpuppc; software (not on my box anyway).</para> </listitem> </itemizedlist> <emphasis>980606</emphasis> <itemizedlist> <listitem><para> The emacs compiled with X libs works, so I think the problem with emacs-nox is probably a generic (application) problem, and not caused in particular by the &linapus; kernel.</para> </listitem> <listitem><para> More reports of problems booting the newest kernels. I'm at a loss here - the kernels are working fine on my box.</para> </listitem> </itemizedlist> <emphasis>980604</emphasis> <itemizedlist> <listitem><para> Merged in a few vger changes and submitted the few &linapus; changes to the vger tree.</para> </listitem> </itemizedlist> <emphasis>980603</emphasis> <itemizedlist> <listitem><para> I replaced the head.S serial progress output with a counter updated in memory. If the kernel hangs for you before it opens a display, have a look at address 0xfff04000 after rebooting. The long word should read 0x1234000?, with ? being between 1 and 8.</para> </listitem> </itemizedlist> <emphasis>980601</emphasis> <itemizedlist> <listitem><para> SCSI drivers are now again included in the precompiled kernels.</para> </listitem> </itemizedlist> <emphasis>980528</emphasis> <itemizedlist> <listitem><para> Exception registers are now mapped with caching enabled.</para> </listitem> <listitem><para> The kernel can now reboot the machine (thanks to Holger Jakob who bugged Ralph Schmidt for the information.)</para> </listitem> <listitem><para> The kernel should now be able to handle weird aligned memory (such as 24MB aligned to an 8MB boundary).</para> </listitem> <listitem><para> While working its way through head.S (early initialization) the kernel now writes the characters A-F to the serial port much like &linm68k;. Caching issues prevents it from being just as detailed as in &linm68k; though.</para> </listitem> <listitem><para> Removed BOOTP/RARP support.</para> </listitem> </itemizedlist> <emphasis>980527</emphasis> <itemizedlist> <listitem><para> Found potential cause of the &blzppc; problems; the first mapping set up before the memory system is initialized used a 64MB mapping instead of the 16MB mentioned in the comment. I changed it to 8MB which should allow a &blzppc; box with only 8MB to boot &linapus;.</para> </listitem> <listitem><para> Included support for msdos partition tables.</para> </listitem> <listitem><para> Put some patches for egcs-1.0.3 in the misc directory at &sunsite;. I don't know how important they are: I've recompiled a working kernel under &linapus; without the patches. The patches are from a posting on the &linppc; kernel list.</para> </listitem> </itemizedlist> <emphasis>980525</emphasis> <itemizedlist> <listitem><para> More patches for vger and the &linm68k; kernel have been submitted.</para> </listitem> <listitem><para> &linapus; is now up-to-date with &linm68k; 2.1.101 and &linppc;-vger-980523. </para> </listitem> <listitem><para> I finally got around to installing a new disk in my &amiga; so I can now do some more testing on it. Also installed &rhppc;/1998.</para> </listitem> <listitem><para> Egcs-1.0.3 has been released. There are still some &linppc;-specific patches which have not been included, but with egcs-1.0.3 and binutils-2.9.1 I can compile a working kernel under &linapus;.</para> </listitem> </itemizedlist> <emphasis>980521</emphasis> <itemizedlist> <listitem><para> Added a new section with mirror sites. First entry is in Poland (thanks Bartek). If you have made a mirror or an archive of the mailing list please let me know.</para> </listitem> <listitem><para> Jimmy "What's-yer-sir-name?" reported that X is finally running on CyberVision. Shortly after Jeffrey W. Davis posted a nice HOWTO on the &linapus; kernel list which I have put in the FAQ section.</para> </listitem> <listitem><para> Most of the remaining &linapus; patches have been applied to the &cpuppc; tree at vger.</para> </listitem> </itemizedlist> <emphasis>980516</emphasis> <itemizedlist> <listitem><para> I added a new section about kernel debugging.</para> </listitem> <listitem><para> I completed the &linm68k;-2.1.99 and vger-980424 merge. I'll upload this diff and start working on merging 2.1.1xx and vger-980514.</para> </listitem> <listitem><para> Sven Ottemann reports that CyberVision is working with the console. X does <emphasis>not</emphasis> work. (old news btw, but now it's in the list).</para> </listitem> </itemizedlist> <emphasis>980514</emphasis> <itemizedlist> <listitem><para> Alex Kazik reports that 980507 change fixed the problems with the GVP 11 SCSI driver.</para> </listitem> </itemizedlist> <emphasis>980512</emphasis> <itemizedlist> <listitem><para> The 980507 change did solve the problem with at least A3000 SCSI. The 53c7xx driver (A4000T+A4091) is also broken under &linm68k; so it will not be fixed by the change.</para> </listitem> <listitem><para> I got my vger merge booting as far as INIT. I'll merge it with 2.1.99 before tracking the last problems down.</para> </listitem> <listitem><para> Removed A4091 and A4000T SCSI drivers from the precompiled kernel.</para> </listitem> </itemizedlist> <emphasis>980507</emphasis> <itemizedlist> <listitem><para> Hopefully fixed kernel_map/VTOP problems. Also cleaned up cache functions. SCSI users should try if this improves things.</para> </listitem> </itemizedlist> <emphasis>980506</emphasis> <itemizedlist> <listitem><para> Removed the sound driver from the precompiled kernel.</para> </listitem> </itemizedlist> <emphasis>980503</emphasis> <itemizedlist> <listitem><para> Completed vger merge. Can't test it though since my shiny new &rh; 5.0 box doesn't like me using the network. I'll re-install 4.2 sometime in the coming week.</para> </listitem> <listitem><para> I think I have found the problem with the SCSI drivers: they use cache_flush/clear with addresses that are not necessarily in kernel space (bounce buffers. user space buffers(?)). The &cpuppc; uses <emphasis>virtual</emphasis> addresses in its cache instructions and PTOV is non-trivial, slow and definitely not working correctly at the moment. Have to give this some serious thought.</para> </listitem> </itemizedlist> <emphasis>980502</emphasis> <itemizedlist> <listitem><para> Thomas Lohmann reports that Ariadne is working.</para> </listitem> <listitem><para> Updated texts about news group and cross-compilation.</para> </listitem> </itemizedlist> <emphasis>980501</emphasis> <itemizedlist> <listitem><para> Jouko Pynnonen reports that &linapus; is finally working on the A1200 &blzppc;.</para> </listitem> <listitem><para> Sven Ottemann updated the <command>hdinstall</command> script.</para> </listitem> <listitem><para> Holger Jakob uploaded an XF86Config example file for 640x480x256 AGA, and a patch for gpm.</para> </listitem> </itemizedlist> <emphasis>980429</emphasis> <itemizedlist> <listitem><para> Tripled SCSI timeouts. </para> </listitem> <listitem><para> Reverted BAT mapping change of 980425. Configurations with non-power-of-two memory sizes fail with this.</para> </listitem> <listitem><para> I have to rewrite the memory mapping to support the &cybppc; HW properly: the &cpuppc; is not happy with the weird alignments caused by growing the memory downwards (as designed by &p5;). If &ados; was using the MMU, I'm sure the memory base would be at the bottom of the addressing space.</para> </listitem> <listitem><para> Changed the CPU speeds for &blzppc; to 50MHz/66MHz.</para> </listitem> <listitem><para> Continue with vger merging.</para> </listitem> </itemizedlist> <emphasis>980428</emphasis> <itemizedlist> <listitem><para> Started to merge the latest vger changes into the &linapus; kernel sources.</para> </listitem> </itemizedlist> <emphasis>980427</emphasis> <itemizedlist> <listitem><para> Use same page fault mechanism on &cpu603; as on &cpu604;. May solve problem with &blzppc;.</para> </listitem> <listitem><para> Realized that some people might have a memory configuration which cannot be mapped with BATs. Added instructions in <xref linkend="booting-linux-apus">.</para> </listitem> <listitem><para> The kernel I build with egcs-1.0.2 after disabling the inline assembly versions of __swab16/32 seems pretty stable.</para> </listitem> </itemizedlist> <emphasis>980426</emphasis> <itemizedlist> <listitem><para> Made a small (fancy :) script which makes it easy to mark changes in the HTML version of this document with colors.</para> </listitem> <listitem><para> Had a go at using egcs to compile the kernel. Didn't work very well. I hope the next egcs release will fix it. If you have the time, please try to get gcc-2.7.2.1 (available from &sunsite; in misc) running under &linapus; and upload the binaries to &sunsite;.</para> </listitem> <listitem><para> Sven Ottemann reports that the floppy driver works with both affs and msdos formatted floppies. </para> </listitem> </itemizedlist> <emphasis>980425</emphasis> <itemizedlist> <listitem><para> Map exception vectors and &cybppc; control vectors with different BATs for improved performance.</para> </listitem> <listitem><para> Unfortunately the last booter changes made it unusable. The 980425 version should be better.</para> </listitem> </itemizedlist> <emphasis>980424</emphasis> <itemizedlist> <listitem><para> Thomas Haller reports that A3000 SCSI actually works if DMA is disabled.</para> </listitem> <listitem><para> Added some progress information to the booter which can be used (hopefully) to find the &blzppc; problems. See FAQ.</para> </listitem> </itemizedlist> <emphasis>980423</emphasis> <itemizedlist> <listitem><para> Fiddled a bit with gcc under &linapus;. The version of gcc I use on Concubine (x86) I cannot get properly working under &linapus;. I have to look into the problems with egcs RSN. I put an additional gcc patch on &sunsite;/misc, but it's probably not worth getting; &linppc; is going to use egcs in the future so I have to get those problems fixed anyways. Stay tuned!</para> </listitem> </itemizedlist> <emphasis>980422</emphasis> <itemizedlist> <listitem><para> Fixed bus_to_virt/virt_to_bus macros. May help A4000T and A4091 drivers.</para> </listitem> </itemizedlist> <emphasis>980421</emphasis> <itemizedlist> <listitem><para> Checked if LPSTOP could be used on the &cpu060; to reduce heat in the box. It cannot.</para> </listitem> <listitem><para> Fixed problem with debug=mem. This may also affect drivers using the VTOP macro.</para> </listitem> </itemizedlist> <emphasis>980420</emphasis> <itemizedlist> <listitem><para> Completed the last part of the FAQ. Added the new kernel mailing list address.</para> </listitem> </itemizedlist> <emphasis>980419</emphasis> <itemizedlist> <listitem><para> Proper bus speed check for A1200 &blzppc;.</para> </listitem> <listitem><para> The new HTML FAQ almost done. Will announce it and the new directory Monday.</para> </listitem> </itemizedlist> <emphasis>980418</emphasis> <itemizedlist> <listitem><para> Added patch from Holger Jakob to allow inclusion of DMA sound.</para> </listitem> </itemizedlist> <emphasis>980417</emphasis> <itemizedlist> <listitem><para> Started work on SGML'ogrifing the FAQ.</para> </listitem> <listitem><para> Got a dedicated directory at &sunsite;. Thanks Karsten!</para> </listitem> </itemizedlist> <emphasis>980416</emphasis> <itemizedlist> <listitem><para> Added a patch from Carsten Pluntke to fix a virtual-to-physical address translation problem causing X to crash.</para> </listitem> <listitem><para> Fixed a potential problem with ioremap. Hopefully SCSI drivers using kernel_map (A4000T/A4091/Fastlane) will now work.</para> </listitem> </itemizedlist> <emphasis>980414</emphasis> <itemizedlist> <listitem><para> Added a &gdb; debugging stub to the kernel sources (not the binaries).</para> </listitem> <listitem><para> Sven Ottemann completed the HD install script. Get <filename>hdinstall.lha</filename> and the newest FAQ for instructions.</para> </listitem> <listitem><para> Added handling for booting on systems where the ROM has been mapped to RAM. (not tested)</para> </listitem> <listitem><para> Added a compiled version of the kernel without the A3000 SCSI driver.</para> </listitem> <listitem><para> Added PPP driver.</para> </listitem> </itemizedlist> <emphasis>980409</emphasis> <itemizedlist> <listitem><para> Added a few extra drivers.</para> </listitem> </itemizedlist> <emphasis>980331</emphasis> <itemizedlist> <listitem><para> Applied some more of Roman's patches.</para> </listitem> <listitem><para> Fixed RAM disk problem.</para> </listitem> </itemizedlist> <emphasis>980326</emphasis> <itemizedlist> <listitem><para> Applied a few of Roman's patches.</para> </listitem> <listitem><para> Changed the way the exception vectors are handled. You have to get the new &boothack; as well (bh980326.lha).</para> </listitem> </itemizedlist> <emphasis>980324</emphasis> <itemizedlist> <listitem><para> Moved the patches to 2.1.90. </para> </listitem> <listitem><para> I still have a few of Roman Zippel's patches that have not been applied.</para> </listitem> </itemizedlist> <emphasis>980316</emphasis> <itemizedlist> <listitem><para> I wrote a small &linapus; FAQ available from &sunsite; in the apus directory.</para> </listitem> </itemizedlist> <emphasis>980224</emphasis> <itemizedlist> <listitem><para> The kernel now auto detects the bus speed.</para> </listitem> <listitem><para> If you have a system with a 60MHz bus speed and press the left mouse button while booting, the memory waitstate will be removed (this requires 60ns RAM).</para> </listitem> </itemizedlist> <emphasis>980223</emphasis> <itemizedlist> <listitem><para> Kernels now compiled for 60MHz and 66MHz busses.</para> </listitem> <listitem><para> Includes a few more drivers.</para> </listitem> </itemizedlist> <emphasis>980216</emphasis> <itemizedlist> <listitem><para> Kernel seems to be working. I experienced some random signals to user processes during the weekend, but was not able to reproduce it. </para> </listitem> <listitem><para> Compiled a version for 50MHz busses with 60ns RAM.</para> </listitem> <listitem><para> Included System.map and .config for reference.</para> </listitem> </itemizedlist> <emphasis>980212</emphasis> <itemizedlist> <listitem><para> Did some more magic with the interrupt handling.</para> </listitem> <listitem><para> Tracked down the problem causing the kernel to hang from time to time (A2065).</para> </listitem> <listitem><para> Compiled two versions of the kernel; one for 50MHz bus and one for 66MHz bus. I will add auto detect soon.</para> </listitem> </itemizedlist> <emphasis>980208</emphasis> <itemizedlist> <listitem><para>Moved my changes to 2.1.85. </para> </listitem> <listitem><para>Cleaned up the handling of interrupts. Mismatch between &p5; doc and actual behavior (&p5; notified).</para> </listitem> <listitem><para>The kernel still hangs from time to time (while processing bottom half interrupt handlers). This might be due to some spurious interrupts, improper interrupt handling, or some problem in the kernel code that only affects &linapus;. I'm looking into it.</para> </listitem> </itemizedlist> <emphasis>980205</emphasis> <itemizedlist> <listitem><para> Added minix support to the kernel. </para> </listitem> <listitem><para> The kernel happily boots the ram disk but is pretty unstable. This is due to improper interrupt handling. I think I have it nailed down, though.</para> </listitem> </itemizedlist> <emphasis>980204</emphasis> <itemizedlist> <listitem><para> Ram disks now work properly (also updated the booter).</para> </listitem> </itemizedlist> <emphasis>980203</emphasis> <itemizedlist> <listitem><para> The patched instructions in the hashing algorithm had to be copied to 0xfff00000 where the exception vectors are located on &linapus;.</para> </listitem> </itemizedlist> <emphasis>980202</emphasis> <itemizedlist> <listitem><para> IDE driver is now working. </para> </listitem> <listitem><para> Kernel hangs when elf_create_table is accessing the stack of the user program to be launched (problem with exception handlers?)</para> </listitem> </itemizedlist> </para> </chapter> <chapter id="people"><title>People</title> <para>Here is a list of the people who helped make &linapus; what it is today. There is also room for <emphasis>your</emphasis> name!</para> <sect1 id="developers"><title>&p5; Appointed Developers</title> <para>&p5; supported the port of &linux; to their &cybppc; hardware by disclosing information about the hardware to:</para> <itemizedlist> <listitem><para>Roman Zippel (<ulink url="mailto:zippel@fh-brandenburg.de"> zippel@fh-brandenburg.de</ulink>)</para> </listitem> <listitem><para>Jes Sørensen (<ulink url="mailto:Jes.Sorensen@cern.ch"> Jes.Sorensen@cern.ch</ulink>)</para> </listitem> <listitem><para>Jesper Skov (<ulink url="mailto:jskov@cygnus.co.uk"> jskov@cygnus.co.uk</ulink>)</para> </listitem> </itemizedlist> </sect1> <sect1 id="contributors"><title>Contributors</title> <para>A few people have started helping with &linapus;. I hope more will join (see <xref linkend="todo-kernel"> and <xref linkend="todo-doc">). If you were not critically deprived of air at birth, and thus do not see the fun in kernel hacking, you can still help. Complement or add sections to &thisdoc;, get responsibility for &debian; or &rh; packages of tools you like, write a helping text for others about a problem you have fought your way through, be helpful on the news group (this would be very appreciated - I can only read news at work and don't always have the time to be helpful myself), send me (or others) grateful emails, or even tons of money. Use your imagination and help make &linm68k; and &linapus; better systems for people with less experience than yourself.</para> <para>There are two parties in particular that I feel deserve kudos: &p5; for helping this port along, and the system administrators at &sunsite; (Karsten Thygesen in particular) for supplying disk space and generally for being a nice bunch (as all Danes are, of course :).</para> <para>For paragraph-sized contributions to &thisdoc;, I put the author's name above the text. Patches to the kernel are rewarded with gratitude and (for bigger stuff) a short mention below. I don't think I want to spend time keeping this part of the document up to date though, so I won't be mentioning every little change. What I will do is to include your name when describing changes in <xref linkend="history"> and make a big'ol' list below with email addresses of contributors (big'n'small).</para> <para>If you feel I have forgotten you, remind me by sending an email (and tons of money).</para> <itemizedlist> <listitem><para> Gerard Cornu(<ulink url="mailto:gcornu@dtr.fr"> gcornu@dtr.fr</ulink>)</para> </listitem> <listitem><para> (<ulink url="mailto:kcci1@central.susx.ac.uk"> kcci1@central.susx.ac.uk</ulink>)</para> </listitem> <listitem><para>Jeff Crystal (<ulink url="mailto:darkmagi@spectrumcp.com"> darkmagi@spectrumcp.com</ulink>)</para> </listitem> <listitem><para>Jeffrey W. Davis (<ulink url="mailto:doctorj@netusa1.net"> doctorj@netusa1.net</ulink>)</para> </listitem> <listitem><para>Christophe Decanini (<ulink url="mailto:cdecanini@yahoo.com"> cdecanini@yahoo.com</ulink>)</para> </listitem> <listitem><para>Marco De Vitis (<ulink url="mailto:marco.dvv@flashnet.it"> marco.dvv@flashnet.it</ulink>)</para> </listitem> <listitem><para>Michel Dänzer (<ulink url="mailto:michdaen@iiic.ethz.ch"> michdaen@iiic.ethz.ch</ulink>)</para> </listitem> <listitem><para>Massimo Gais (<ulink url="mailto:ftpadmin@ftp.unina.it"> ftpadmin@ftp.unina.it</ulink>)</para> </listitem> <listitem><para>Duncan Gibb (<ulink url="mailto:Duncan.Gibb@ed.ac.uk"> Duncan.Gibb@ed.ac.uk</ulink>) WB GUI boot script (oh yes you do! :)</para> </listitem> <listitem><para>Matthias Goerdeler (<ulink url="mailto:goerdler@hp1.imm.rwth-aachen.de"> goerdler@hp1.imm.rwth-aachen.de</ulink>)</para> </listitem> <listitem><para>Arno Griffioen (<ulink url="mailto:arno@usn.nl"> arno@usn.nl</ulink>)</para> </listitem> <listitem><para>Sinan Gurkan (<ulink url="mailto:sgurkan@artemis.efes.net"> sgurkan@artemis.efes.net</ulink>)</para> </listitem> <listitem><para>Thomas Haller (<ulink url="mailto:Thomas-h8t.Haller@ubs.ch"> Thomas-h8t.Haller@ubs.ch</ulink>)</para> </listitem> <listitem><para>Gordon Huby (<ulink url="mailto:gordon@ghuby.freeserve.co.uk"> gordon@ghuby.freeserve.co.uk</ulink>)</para> </listitem> <listitem><para>Mecha Ike (<ulink url="mailto:mecha.ike@thecure.co.uk"> mecha.ike@thecure.co.uk</ulink>)</para> </listitem> <listitem><para>Holger Jakob (<ulink url="mailto:jakob@ph-cip.Uni-Koeln.DE"> jakob@ph-cip.Uni-Koeln.DE</ulink>)</para> </listitem> <listitem><para>Jens Kristian Jensen (<ulink url="mailto:judas@cs.auc.dk"> judas@cs.auc.dk</ulink>)</para> </listitem> <listitem><para>Jimmy (<ulink url="mailto:Jimmy@Stud-Mailer.Uni-Marburg.DE"> Jimmy@Stud-Mailer.Uni-Marburg.DE</ulink>)</para> </listitem> <listitem><para>Alex Kazik (<ulink url="mailto:martin.koenig@gmx.net"> martin.koenig@gmx.net</ulink>)</para> </listitem> <listitem><para> Martin Koenig(<ulink url="mailto:alx@gmx.de"> alx@gmx.de</ulink>)</para> </listitem> <listitem><para>Bartek Kozakiewicz (<ulink url="mailto:coza@snickers.ek.univ.gda.pl"> coza@snickers.ek.univ.gda.pl</ulink>)</para> </listitem> <listitem><para>Chris Lawrence (<ulink url="mailto:quango@watervalley.net"> quango@watervalley.net</ulink>)</para> </listitem> <listitem><para>Thomas Lohmann (<ulink url="mailto:tlohmann@scobs.de"> tlohmann@scobs.de</ulink>)</para> </listitem> <listitem><para>Sven Luther (<ulink url="mailto:luther@dpt-info.u-strasbg.fr"> luther@dpt-info.u-strasbg.fr</ulink>) SCSI support for Blizzard controllers.</para> </listitem> <listitem><para>Peter McGavin (<ulink url="mailto:P.McGavin@irl.cri.nz"> P.McGavin@irl.cri.nz</ulink>)</para> </listitem> <listitem><para>Carlos Mayo (<ulink url="mailto:COMPMAY@teleline.es"> COMPMAY@teleline.es</ulink>)</para> </listitem> <listitem><para>Ilario Nardinocchi (<ulink url="mailto:nardicon@cs.unibo.it"> nardicon@cs.unibo.it</ulink>) CVPPC driver.</para> </listitem> <listitem><para>Sven Ottemann (<ulink url="mailto:Sven.Ottemann@Student.Uni-Magdeburg.DE"> Sven.Ottemann@Student.Uni-Magdeburg.DE</ulink>) Hard disk install script for the &rh; base system.</para> </listitem> <listitem><para>Frank Petzold (<ulink url="mailto:fpetzold@hepe.com"> fpetzold@hepe.com</ulink>)</para> </listitem> <listitem><para>Carsten Pluntke (<ulink url="mailto:su0289@sx2.hrz.uni-dortmund.de"> su0289@sx2.hrz.uni-dortmund.de</ulink>) Fixed vm problem with X.</para> </listitem> <listitem><para>Jouko Pynnonen (<ulink url="mailto:pynjo@jytol.fi"> pynjo@jytol.fi</ulink>)</para> </listitem> <listitem><para>Robert Ramiega (<ulink url="mailto:robert@plukwa.pdi.net"> robert@plukwa.pdi.net</ulink>)</para> </listitem> <listitem><para>Francisco Sepulveda (<ulink url="mailto:Francisco.Sepulveda@ico.unil.ch"> Francisco.Sepulveda@ico.unil.ch</ulink>)</para> </listitem> <listitem><para>Christian T. Steigies (<ulink url="mailto:steigies@physik.uni-kiel.de"> steigies@physik.uni-kiel.de</ulink>)</para> </listitem> <listitem><para>Ken (& Julian) Tyler (<ulink url="mailto:kent@werple.net.au"> kent@werple.net.au</ulink>) Fixed the &rhinstaller; scripts to work with &linapus;.</para> </listitem> <listitem><para>Geert Uytterhoeven (<ulink url="mailto:Geert.Uytterhoeven@cs.kuleuven.ac.be"> Geert.Uytterhoeven@cs.kuleuven.ac.be</ulink>) X server binaries. &rhppc; base system archive and installation help. Santa's little vger helper :)</para> </listitem> </itemizedlist> </sect1> <sect1 id="contributing"><title>Contributing</title> <para>If you have any contributions to &linapus; (code, ideas, changes to &thisdoc;, whatever) please send them to the &linapus; kernel mailing list. Archives and/or packages can be uploaded to <xref linkend="sd-incoming"> <emphasis>(remember to notify me via mail)</emphasis>.</para> </sect1> </chapter> <chapter id="links"><title>Links</title> <para> If you have an idea for additional (&linapus; relevant) links, please let me know.</para> <sect1 id="linux-links"><title>&linux; Links</title> <informaltable frame="all"> <tgroup cols="3"> <tbody> <row> <entry align="center"><emphasis>&linapus;</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>FTP Location</emphasis> </entry> </row> <row> <entry>&linapus; Master Site </entry> <entry><ulink url="http://sunsite.auc.dk/ftp/projects/apus"> sunsite.auc.dk/ftp/projects/apus</ulink> </entry> <entry><ulink url="ftp://sunsite.auc.dk/projects/apus"> sunsite.auc.dk/projects/apus</ulink> </entry> </row> <row> <entry>&linapus; Poland Mirror </entry> <entry> </entry> <entry><ulink url="ftp://snickers.ek.univ.gda.pl/pub/apus"> snickers.ek.univ.gda.pl/pub/apus</ulink> </entry> </row> <row> <entry>&linapus; Italian Mirror </entry> <entry> </entry> <entry><ulink url="ftp://ftp.unina.it"> ftp.unina.it</ulink> </entry> </row> <row> <entry>Amiga Format CD40 unofficial support site </entry> <entry><ulink url="http://http://members.tripod.com/~DuncanG/"> http://members.tripod.com/~DuncanG/</ulink> </entry> <entry> </entry> </row> <row> <entry align="center"><emphasis>&linm68k;</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>FTP Location</emphasis> </entry> </row> <row> <entry>&linm68k; Kernel Master Site </entry> <entry><ulink url="http://sunsite.auc.dk/ftp/projects/680x0"> sunsite.auc.dk/ftp/projects/680x0</ulink> </entry> <entry><ulink url="ftp://sunsite.auc.dk/projects/680x0"> sunsite.auc.dk/projects/680x0</ulink> </entry> </row> <row> <entry>&linm68k; Home Page </entry> <entry><ulink url="http://www.linux-m68k.org"> www.linux-m68k.org</ulink> </entry> <entry> </entry> </row> <row> <entry>Permedia2 (CyberVision/PPC) Frame Buffer Home Page </entry> <entry><ulink url="http://www.cs.unibo.it/~nardinoc/pm2fb/"> http://www.cs.unibo.it/~nardinoc/pm2fb/</ulink> </entry> <entry> </entry> </row> <row> <entry align="center"><emphasis>&linppc;</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>FTP Location</emphasis> </entry> </row> <row> <entry>&linppc; Master Site </entry> <entry><ulink url="http://www.linuxppc.org"> www.linuxppc.org</ulink> </entry> <entry><ulink url="ftp://ftp.linuxppc.org"> ftp.linuxppc.org</ulink> </entry> </row> <row> <entry align="center"><emphasis>&debppc;</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>FTP Location</emphasis> </entry> </row> <row> <entry>The &debppc; port </entry> <entry><ulink url="http://www.debian.org/ports/powerpc/"> www.debian.org/ports/powerpc/</ulink> </entry> <entry> </entry> </row> <row> <entry>&debppc; packages </entry> <entry> </entry> <entry><ulink url="ftp://ftp.debian.org/debian/dist/main/binary-powerpc/"> ftp.debian.org/debian/dist/main/binary-powerpc/</ulink> </entry> </row> <row> <entry>&debppc; install stuff </entry> <entry> </entry> <entry><ulink url="ftp://ftp.debian.org/debian/dists/sid/main/disks-powerpc/2.0.11.4_1998-10-15/"> ftp.debian.org/debian/dists/sid/main/disks-powerpc/2.0.11.4_1998-10-15/</ulink> </entry> </row> <row> <entry align="center"><emphasis>&linux; Help</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>Comment</emphasis> </entry> </row> <row> <entry>Linux Portal </entry> <entry><ulink url="http://www.linux.org"> www.linux.org</ulink> </entry> <entry></entry> </row> <row> <entry>News Archive </entry> <entry><ulink url="http://www.dejanews.com"> www.dejanews.com</ulink> </entry> <entry>Search for keywords, include "linux" </entry> </row> <row> <entry>WEB Search </entry> <entry><ulink url="http://www.altavista.com"> www.altavista.com</ulink> </entry> <entry>Search for keywords, include "linux" </entry> </row> <row> <entry>MiningCo </entry> <entry><ulink url="http://linux.miningco.com"> linux.miningco.com</ulink> </entry> <entry>Search for keywords </entry> </row> <row> <entry align="center"><emphasis>&linux; Kernel Hacking </emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>Comment</emphasis> </entry> </row> <row> <entry>&linux; Kernel (Hacking) FAQ </entry> <entry><ulink url="http://www.tux.org/lkml/"> www.tux.org/lkml/</ulink> </entry> <entry> </entry> </row> </tbody> </tgroup> </informaltable> <sect2><title>Software Packages</title> <informaltable frame="all"> <tgroup cols="3"> <tbody> <row> <entry align="center"><emphasis>Software</emphasis> </entry> <entry align="center"><emphasis>HTTP Location</emphasis> </entry> <entry align="center"><emphasis>FTP Location</emphasis> </entry> </row> <row> <entry>binutils </entry> <entry> </entry> <entry><ulink url="ftp://prep.ai.mit.edu">prep.ai.mit.edu</ulink>, <ulink url="ftp://sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/"> sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/</ulink> </entry> </row> <row> <entry>egcs </entry> <entry><ulink url="http://egcs.cygnus.com">egcs.cygnus.com</ulink> </entry> <entry><ulink url="ftp://egcs.cygnus.com">egcs.cygnus.com</ulink>, <ulink url="ftp://sunsite.auc.dk/mirrors/egcs.cygnus.com"> sunsite.auc.dk/mirrors/egcs.cygnus.com</ulink> </entry> </row> <row> <entry>Mozilla </entry> <entry><ulink url="http://www.mozilla.org">www.mozilla.org</ulink> </entry> <entry><ulink url="ftp://ftp.mozilla.org">ftp.mozilla.org</ulink> </entry> </row> <row> <entry>&rhppc; </entry> <entry><ulink url="http://www.linuxppc.org"> www.linuxppc.org</ulink> </entry> <entry><ulink url="ftp://ftp.linuxppc.org"> ftp.linuxppc.org</ulink> </entry> </row> <row> <entry>X </entry> <entry><ulink url="http://www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz"> www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz</ulink> </entry> <entry> </entry> </row> </tbody> </tgroup> </informaltable> </sect2> <sect2><title>Related &cybppc; and &ados; Sites</title> <para>&p5; <ulink url="http://www.phase5.de">www.phase5.de</ulink>.</para> </sect2> </sect1> </chapter> <chapter id="sunsite"><title>&sunsite;</title> <para><ulink url="http://sunsite.auc.dk">&sunsite;</ulink> is the main distribution site for both the &linm68k; and &linapus; kernels (no, it's not a coincidence: both Jes and I studied at Aalborg University). There's lots of other good stuff there, and it's well worth a visit. You can access it by both HTTP and FTP (using the same hostname and paths).</para> <para>You can find &linm68k; related stuff (including the &linm68k; FAQ) in the directory <ulink url="http://sunsite.auc.dk/ftp/local/os/linux/680x0/"> sunsite.auc.dk/ftp/local/os/linux/680x0/</ulink>.</para> <para>The &linapus; directory is <ulink url="http://sunsite.auc.dk/ftp/projects/apus/"> sunsite.auc.dk/ftp/projects/apus/</ulink>. This directory contains the following (and possibly more; have a look around):</para> <itemizedlist> <listitem id="sd-deb" xreflabel="the 'DEB-APUS' directory at &sunsite;"> <para>DEB-APUS</para> <para> Directory with &debian; packages recompiled especially for &linapus;. I need <emphasis>your</emphasis> help to get it filled with good stuff!</para> </listitem> <listitem id="sd-rpm" xreflabel="the 'RPM-APUS' directory at &sunsite;"> <para>RPM-APUS</para> <para> Directory with &rh; packages recompiled especially for &linapus;. I need <emphasis>your</emphasis> help to get it filled with good stuff!</para> </listitem> <listitem id="sd-boothack" xreflabel="the 'boothack' directory at &sunsite;"> <para>boothack</para> <para> Directory with the special version of &amiboot; required to boot a &linapus; kernel.</para> </listitem> <listitem id="sd-contrib" xreflabel="the 'contrib' directory at &sunsite;"> <para>contrib</para> <para> Directory where I put kernel images and diffs contributed by users. If you want to contribute, upload to incoming and notify me via mail <footnote id="ft-readme"><para>I only accept uploads with an accompanying <filename>.readme</filename> file containing:</para> <itemizedlist> <listitem><para><emphasis>Uploader:</emphasis> Name and email address.</para> </listitem> <listitem><para><emphasis>Contents:</emphasis> Archive description and/or a description of why people should use it.</para> </listitem> </itemizedlist> <para>Also, please make sure to notify me when an archive becomes obsolete so it can be deleted.</para> </footnote>.</para> </listitem> <listitem id="sd-docs" xreflabel="the 'docs' directory at &sunsite;"> <para>docs</para> <para> Directory with &thisdoc; in HTML and SGML formats. The file <filename>faq-all.tgz</filename> contains all the files for easy downloading.</para> </listitem> <listitem id="sd-incoming" xreflabel="the 'incoming' directory at &sunsite;"> <para>incoming</para> <para> Directory where you can upload contributions <footnoteref linkend="ft-readme">.</para> </listitem> <listitem id="sd-install" xreflabel="the 'install' directory at &sunsite;"> <para>install</para> <para> Directory with installation related files and directories..</para> </listitem> <listitem id="sd-install-rh" xreflabel="the &rh; 'install' directory at &sunsite;"> <para>install/redhat</para> <para> Directory with files required to create a &rhppc; or &rhrc; system.</para> </listitem> <listitem id="sd-install-deb" xreflabel="the &debian; 'install' directory at &sunsite;"> <para>install/debian</para> <para> Directory with files required to create a &debian; system.</para> </listitem> <listitem id="sd-22x" xreflabel="the '2.2.x' directory at &sunsite;"> <para>2.2.x</para><para> Directory with stable kernel binaries and diffs.</para> </listitem> <listitem id="sd-23x" xreflabel="the '2.3.x' directory at &sunsite;"> <para>2.3.x</para><para> Directory with developer kernel diffs.</para> </listitem> <listitem id="sd-misc" xreflabel="the 'misc' directory at &sunsite;"> <para>misc</para> <para> Directory with miscellaneous tidbits, such as the build tools I'm using to make the precompiled kernel images.</para> </listitem> </itemizedlist> <para>The &linapus; kernel mailing list is also hosted by &sunsite;. Send for help at <ulink url="mailto:linux-apus-help@sunsite.auc.dk"> linux-apus-help@sunsite.auc.dk</ulink>. The list is also available via NTTP from <ulink url="news://sunsite.auc.dk">sunsite.auc.dk</ulink> (look for sunsite.linux.apus). Please read <xref linkend="etiquette"> before posting to this list.</para> <sect1 id="linux-apus-mirror-sites"> <title>&linapus; Mirror Sites</title> <para>The <filename class=directory>apus</filename> directory at &sunsite; is mirrored a few places thanks to the people mentioned in parenthesis:</para> <para>Poland (FTP): <ulink url="ftp://snickers.ek.univ.gda.pl/pub/apus"> snickers.ek.univ.gda.pl/pub/apus</ulink> (Bartek Kozakiewicz)</para> <para>Italy (FTP): <ulink url="ftp://ftp.unina.it"> ftp.unina.it</ulink> (Massimo Gais)</para>  <para>If you have the space (and time?) to make a mirror of either the <filename class=directory>apus</filename> directory at &sunsite; or make an archive of the &linapus; kernel mailing list, please let me know. &sunsite; is close and convenient to use for me, but that may not be so for others.</para> </sect1> </chapter> <chapter id="developer-sections"><title>Developer Sections</title> <para>This part of the document is intended for developers and people who just like to live on the edge, compiling their own kernel.</para> <sect1 id="dev-the-kernel-diffs"><title>The Kernel Diffs</title> <para> This section describes how you can recompile your own kernel. It may be necessary to do if the prebuilt kernels do not contain drivers for some of your equipment. Rebuilding the kernel including only drivers for the equipment you have may also result in slightly more memory available for applications.</para> <para> The diff files found at &sunsite; are relative to the last release of the &linm68k; developer sources. The diffs are named <filename>linux-2.2.8-m68k-YYMMDD.diff.gz</filename> (2.2.8 is the current &linm68k; version at the time of writing - you may find patches for more recent kernels). </para> <para> Always apply my patches to a clean set of &linm68k; sources as found on &sunsite; to avoid getting rejects. My diffs may include (parts) of patches posted to the &linm68k; kernel list.</para> <para> I have also started uploading &linapus; relative diffs. These are named <filename>linux-apus-YYMMDD.diff.gz</filename> and are relative to the previous &linapus; release.</para> <para> So, in order to get yourself a set of &linapus; kernel sources, download the latest &linm68k; sources (e.g., <filename>linux-2.2.8.tar.gz</filename>). Unpack these and apply a version-matching &linm68k;-&linapus; diff (e.g., linux-2.2.8-m68k-990516.diff). When you want to upgrade the &linapus; sources later on, get the incremental &linapus; patches (e.g., linux-apus-990517.diff and linux-apus-990518.diff) and apply these in turn (to get from 990516 sources to 990518 sources). When you have downloaded the &linm68k; kernel sources once, you should be able to remain up-to-date using only &linapus; incremental patches. </para> <sect2 id="dev-recompile"><title>Recompiling Your Own Kernel</title> <para> Both because the precompiled kernels are so big, and because the set of included drivers may change without notice, you should recompile your own customized kernel when you have used a precompiled kernel to install your system.</para> <para>If you want to help (actively) with the development of &linm68k; and/or &linapus; you also need to recompile your own kernel (yes, <emphasis>you</emphasis> can hack the kernel. All that is really required is build tools, patience, a bit of interest in the subject and possibly some C knowledge (I learned C by hacking &linux; -- see the two previous requirements :))</para> <para>It is possible to get a reasonable stable kernel by following the advice below. Many people who have problems with the kernels they build themselves usually didn't follow the below advice. In particular, use the specified tool versions even if newer are available. And build the tools yourself since prebuilt tools may include patches that could foul things up.</para> <para> You can find binutils at <ulink url="ftp://prep.ai.mit.edu">prep.ai.mit.edu</ulink> or one of its mirrors (e.g., <ulink url="ftp://sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/"> sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/</ulink>). You can find egcs at <ulink url="ftp://egcs.cygnus.com">egcs.cygnus.com</ulink> or one of its mirrors (e.g., <ulink url="ftp://sunsite.auc.dk/mirrors/egcs.cygnus.com"> sunsite.auc.dk/mirrors/egcs.cygnus.com</ulink>).</para> <para> Still, since it is a developer kernel, your mileage may vary, even if you painstakingly follow the below.</para> <para> <emphasis>Note: There has been reported problems with rebuilding egcs-1.1 from the source code archive; it requires a C++ compiler, even if you specify LANGUAGES to only include C. Workaround is to build everything (i.e., don't use the LANGUAGES option).</emphasis></para> <sect3><title>Basic Kernel Compilation</title> <para> A good way to start compiling your own kernel is by using the configuration I use to build kernels. That way, you can be sure that the kernel will build without problems, and you can test that it works just as well as the ones I have built.</para> <para> First patch the kernel:</para> <screen> tar xzf linux-2.1.115.tar.gz cd linux-2.1.115 patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff</screen> <para> Then copy the <filename>.config</filename> from one of the archives with precompiled kernels to the kernel directory, configure and build the kernel:</para> <screen> cp [path of prebuilt kernel]/.config . make oldconfig make dep make </screen> <para> Now test the kernel. If it works, reconfigure to suit your system and rebuild. Resolve problems as they appear and send patches to the list :)</para> </sect3> <sect3><title>Native Compilation</title> <para>If you know how to recompile &linm68k; there shouldn't be much of a difference - except that it will be done faster :)</para> <orderedlist> <listitem><para> Get binutils-2.9.1 and egcs-1.1.</para> </listitem> <listitem><para> Configure, build and install binutils.</para> <screen> tar xzf binutils-2.9.1.tar.gz cd binutils-2.9.1 ./configure make make install cd .. </screen> </listitem> <listitem><para>Configure, build and install egcs.</para> <screen> tar xzf egcs-1.1.tar.gz cd egcs-1.1 mkdir build cd build ../configure make LANGUAGES=c make LANGUAGES=c install </screen> </listitem> <listitem><para> Get the latest &linm68k; kernel sources (2.1.115 as of the time of writing) and apply the &linapus; patch.</para> <screen> tar xzf linux-2.1.115.tar.gz cd linux-2.1.115 patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff</screen> </listitem> <listitem><para> Configure and compile the kernel.</para> <screen> make config [select the options you want] make dep make </screen> </listitem> <listitem><para> Boot your shiny new kernel (see <xref linkend="booting-linux-apus">).</para> </listitem> </orderedlist> </sect3> <sect3><title>Cross-Compilation</title> <para> This is probably what you want to do if you want to do some serious &linapus; development as it cuts down the time of the build-boot-test cycle dramatically. You need a slave box (like my PC 'Concubine') on which you do the editing and building and a proper connection to the &amiga; (I used serial for some months, but can warmly recommend an Ethernet card).</para> <para>Using a different build machine also allows you to get serial output from the kernel you are testing and/or use a remote debugger (beats <function>printk</function>-debugging, I'm sure) if you connect the machines with a null-modem cable.</para> <para>You need a cross compilation environment, targeting big-endian &cpuppc; ELF files. Here's how to build the required binutils and compiler on another &linux; box:</para> <orderedlist> <listitem><para>Get binutils-2.9.1 and egcs-1.1.</para> </listitem> <listitem><para>Configure, build and install binutils for target </para> <screen> tar xzf binutils-2.9.1.tar.gz cd binutils-2.9.1 mkdir build cd build ../configure --target=powerpc-unknown-linux make make install </screen> <para> You should now have binutils targeted for &cpuppc; installed in <filename class=directory> /usr/local/bin</filename>. Make sure this directory is in your PATH.</para> </listitem> <listitem><para> Get the files from <filename class=directory> /usr/include</filename> of your &linapus; box and put them in the <filename class=directory> /usr/local/powerpc-unknown-linux/include</filename> directory of your build machine. (The files are also available from <xref linkend="sd-misc">.) Make sure that the <filename>asm</filename> and <filename>linux</filename> links point to the location of those directories in the linux source code you are trying to compile (i.e., <filename class="directory">/usr/src/linux/include/asm</filename> and <filename class="directory">/usr/src/linux/include/linux</filename>) .</para> </listitem> <listitem><para>Configure egcs for cross-compilation.</para> <screen> tar xzf egcs-1.1.tar.gz cd egcs-1.1 mkdir build cd build ../gcc/configure --target=powerpc-unknown-linux make LANGUAGES=c make LANGUAGES=c install </screen> <para> You should now have gcc targeted for &cpuppc; installed in <filename> /usr/local/bin/powerpc-unknown-linux-gcc</filename>.</para> </listitem> <listitem><para>Configure and build the kernel.</para> <screen> make config [select the options you want] make dep make </screen> <para>Notice that the kernel will be build using the cross-compiler, <filename>powerpc-unknown-linux-gcc</filename> which automatically uses the correct &cpuppc; binutils.</para> </listitem> <listitem><para>Copy the kernel to your &amiga;.</para> </listitem> <listitem><para>Boot your shiny new (cross-compiled) kernel (see <xref linkend="booting-linux-apus">).</para> </listitem> </orderedlist> <para>There's a cross-compiling mini HOWTO at <ulink url="ftp://ftp.uni-erlangen.de:/pub/Linux/680x0/docs/cross-compiling-Mini-HOWTO"> ftp://ftp.uni-erlangen.de:/pub/Linux/680x0/docs/cross-compiling-Mini-HOWTO</ulink> you can consult if you need more help.</para> </sect3> </sect2> </sect1> <sect1 id="dev-kernel-debugging"><title>Kernel Debugging</title> <para>The kernel contains bugs. Period. Fact of life. Some are just small annoyances, others are show stoppers. Bugs in the latter category are usually (and fortunately) easy to track down given enough information.</para> <para>In this section I will try to explain what you need to report when you find a bug so it is easier for others to fix it. If you feel like looking into the problem yourself (please do!) this may be used as a brief guide of what to look for.</para> <sect2><title>Interactive Debugging</title> <para>Newer kernels contain a stub which makes it possible to debug the kernel in &gdb; via a serial line from another &linux; host. This is <emphasis>the</emphasis> way to debug something since you have access to registers and memory while the system is still alive - or at the time of its death.</para> <para>[Unfortunately, I don't know if this interface is working properly. I hope to get it tested RSN. I will add some more text about it when I know more.]</para> </sect2> <sect2><title>Non-interactive Debugging</title> <para>Sometimes interactive debugging is not an option and you have to rely on <function>printk</function> calls. Basically you insert some <function>printk</function>s with different texts in places of the kernel where you suspect there is a problem.</para> <para>You can ouput variable values and thereby check that the values are what you expect them to be. Output strings throughout the flow of a function to check that it executes the expected if-statements, does the correct number of iterations or to get an idea of where it hangs. Use your imagination and be generous - each time you decide to insert more <function>printk</function>s you have to rebuild the kernel and reboot; you might as well put in plenty to start with.</para> <para>Debugging <filename>head.S</filename> is a bit more tricky. I use a handful of serial-print assembly routines by Roman Zippel. These can be found in the file <filename>arch/ppc/kernel/debug.h</filename> - include it from <filename>head.S</filename>, call <function>initserial</function> from somewhere in the top of the code and use the other functions to output characters/values where you want to investigate something. You must use functions <function>foo</function> when memory mapping is disabled and functions <function>foo2</function> when memory mapping is enabled.</para> <sect3><title>Debug Options</title> <para>The text from the <function>printk</function>s go to the console. Sometimes it makes sense to output the text to memory so you can save it for later reference or analysis. Use <option>debug=mem</option> as an option to bootstrap when booting and after reseting, run &dmesg; (from <xref linkend="sd-misc">) under &ados;. It should find the text.</para> <para>You can also use the option <option>debug=ser</option> which will output the text over the builtin serial line at 9600 baud.</para> </sect3> <sect3><title>Standard Debug Output</title> <para>If a user application causes an exception it will be terminated without affecting any other application running. However, if the kernel causes an exception there is no way of handling it gracefully. In those situations the kernel will dump some information on the console which may help developers track the problem down. It may look like this:</para> <screen> NIP: C00D4EA4 XER: 00000000 LR: C00D6E64 REGS: c3c83bd0 TRAP: 0700 MSR: 00089972 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c3c82000[130] 'mingetty' mm->pgd c2856000 Last syscall: 4 last math 00000000 GPR00: 00000000 C3C83CC0 C3C82000 C02C2FC0 00000002 00000000 00000019 00000050 GPR08: 00000000 C01528B4 C02C2FC0 00000000 3004E158 0024BB94 C017C6E0 C017C6E0 GPR16: C3EAC000 00000002 C0150000 C01704F8 00000001 00000000 00000000 C3C83D8A GPR24: 00203578 C3F5C4A0 00000001 00000000 C02C30D4 00000000 000007D0 00000000 Call backtrace: C004D580 C00D6E64 C00D7C94 C00D8710 C00CA630 C00CC4F4 C00C7988 C0026818 C000447C 00201570 00201D18 002010B8 Kernel panic: Exception in kernel pc c00d4ea4 signal 4 Rebooting in 180 seconds.. </screen> <para> The NIP (next instruction pointer) tells what instruction caused the exception and the contents of the other registers can help explain why. The call backtrace shows the call sequence resulting in the exception allowing you to examine those functions (in the source code) and possibly insert a breakpoint (&gdb;) or <function>printk</function>s to help track down the problem.</para> <para>However, since these addresses are specific to the kernel you are running, a dump like the above is not necessarily of much help to kernel hackers. In order to help them you need to use the tool <application>ksymoops</application> (source found in the <filename class=directory>scripts</filename> directory of the kernel sources) which will use the <filename>System.map</filename> file to produce a more usable dump you can send to the kernel list.</para> <para>When you have found out which function the exception was caused by (look up the address in the <filename>System.map</filename> file) you might be able to make a quick fix. If the function belongs to a driver that is not properly supported you can disable it when doing <command>make config</command>. If the driver accepts kernel options you might want to use some other options than the default or the ones you used when the exception occurred.</para> </sect3> <sect3><title>Other Helpful Information</title> <para>The exception you experience may be caused by many things. Kernel hackers <emphasis>may</emphasis> have an idea of what is most likely to be the culprit. You can help them narrow down the list of potential problems by including the following information:</para> <itemizedlist> <listitem><para> The bootstrap line you use to start the kernel (so we can see what options you used).</para> </listitem> <listitem><para> The output from bootstrap when using the <option>-d</option> option (so we can see what configuration you have).</para> </listitem> <listitem><para> The kernel debug output (use <option>debug=mem</option> and &dmesg; as described earlier).</para> </listitem> <listitem><para> If you need to do something in particular to cause the exception, tell us so we can try to reproduce it.</para> </listitem> </itemizedlist> </sect3> </sect2> </sect1> </chapter> </book>