<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"[
<!ENTITY mailinglist "linuxppc-embedded mailing list">
<!ENTITY author "Boas Betzler">
]>
<article id="PowerPC-Embedded-HOWTO">
					
<articleinfo>
	<title>Linux for PowerPC Embedded Systems HOWTO</title>

	<author><firstname>Boas</firstname>
	<surname>Betzler</surname>
	</author>
	<address>
	<email id="author">	<ulink
	url="mailto:boas@de.ibm.com?subject=Feedback on
	PowerPC-Embedded-HOWTO">boas@de.ibm.com</ulink>
	</email>
	</address>
	<date>21 August 2001</date>

</articleinfo>

	<abstract>
		<para>A distillation of the collective wisdom from the
	 	<link linkend="mail">&mailinglist;</link> on how to
	 	build an embedded PowerPC-based Linux system.</para>
	</abstract>

<sect1>
	<title>Introduction</title>

	<para>This document is an attempt to tell you what you need to
	know to use Linux on an embedded PowerPC-based system, and is
	a distillation of the collective wisdom from the <link
	linkend="mail">&mailinglist;</link>. Comments, feedback and
	corrections to this document are invited via e-mail to the
	<ulink url="mailto:boas@de.ibm.com?subject=Feedback on
	PowerPC-Embedded-HOWTO">author</ulink>. </para>
  
	<para>Some of the information here is in the form of
	references to the mailing list archives. Follow the threads in
	the archive to get more information.</para>

	<para>This document is laid out roughly in the order of the
	steps necessary to implement a complete system, which is
	similar to boot order starting at the lowest level and working
	upwards. </para>

	<sect2>
		<title>Copyright</title>

		<para>Copyright &copy; 2001, IBM Corp. </para>

		<para>Copyright &copy; 2000, Canon Information
		Systems Research Australia. </para>

		<para>Permission is granted to copy, distribute and/or
		modify this document under the terms of the GNU Free
		Documentation License, Version 1.1 or any later
		version published by the Free Software Foundation;
		with no Invariant sections, with no Front-Cover Texts,
		and with no Back-Cover Texts. A copy of the license is
		included in <xref linkend="gfdl"></para>

		<para>The views expressed here are not necessarily
		those of CISRA or Canon Inc or IBM Corp.</para>

	</sect2>

	<sect2>
		<title>Updates</title>

		<para>The latest HTML version of this document is
		available online at <ulink
		url="http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.html">
                http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.html</ulink>
		</para>

		<para>If you want to print or reformat this document,
		you might find the SGML source useful at <ulink
		url="http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.sgml">
		http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.sgml</ulink>
		</para>

	</sect2>

	<sect2 id="credits">
		<title>Credits</title>
		<para>Based on the original HOWTO which was written by 
                Graham Stoney, now Boas Betzler is maintaining this document.
                It is assembled  
		utilising the wisdom dispensed by many others,
		particularly the gurus in the field: Dan Malek, Cort
		Dougan, Marcus Sundberg, Wolfgang Denk, Richard
		Hendricks, Matt Porter, Grant Erickson, Darvis Nevil,
		Murray Jensen, Matthew Locke and others. They deserve the credit - I
		doubt you'll find a more helpful group of
		people. </para>
	</sect2>

</sect1>

<sect1>
	<title>Resources</title>

	<para>The most relevant net resources are:</para>

	<sect2>
		<title>Home Page</title>

		<para><ulink
		URL="http://penguinppc.org/embedded/">
                http://penguinppc.org/embedded</ulink> </para>

		<para>Introductory stuff.</para>
	</sect2>

	<sect2 id="ftp">
		<title>FTP site</title>

 		<para>The <ulink
		url="ftp://ftp.mvista.com/pub/CDKit/1.2/">MontaVista
		FTP</ulink> site is a good starting point.</para>
	</sect2>

	<sect2 id="mail">
		<title>Mailing List</title>

		<para><ulink
		url="http://lists.linuxppc.org/lists/linuxppc-embedded">
		http://lists.linuxppc.org/lists/linuxppc-embedded</ulink>
		</para>

		<para>The archive contains indispensable wisdom
		answering most of your questions before you knew you
		needed to ask them. Browse it heavily. </para>

		<para>In particular, look for any articles by the
		individual gurus mentioned in <xref
		linkend="credits">.  Unfortunately you can't search
		the archives by <action>From:</action> line to do this
		yet.</para>

		<para>You are encouraged to subscribe by visiting
		<ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/info.html">http://lists.linuxppc.org/listarcs/linuxppc-embedded/info.html</ulink></para>

		<para>However, please search the archives before asking
		questions. </para>

		<para>Instructions like "Search for ..." in this
		document refer directly to the search engine at the
		mailing list archives for the specified
		keyword. Follow the keyword link to perform the
		search. </para>
	</sect2>

	<sect2>
		<title>Home of the linux/ppc port</title>
		<para><ulink
		url="http://penguinppc.org/">http://penguinppc.org/</ulink>
		</para>
	</sect2>

	<sect2>
		<title>PowerPC Programming</title>

		<para>The ABI and EABI documentation describing
		register usage and C linkage conventions are available
		at: <ulink
		url="http://www.esofta.com/softspecs.html">http://www.esofta.com/softspecs.html
		</ulink> </para>
		
		<para>There is lots of invaluable information about 
		optimisations for the PowerPC architecture in the IBM
		PowerPC Compiler Writer's Guide at: <ulink
		url="http://www.chips.ibm.com/products/powerpc/tools/compiler/cover.html">
                http://www.chips.ibm.com/products/powerpc/tools/compiler/cover.html</ulink></para>
	</sect2>

	<sect2>
		<title>Usenet Groups</title>

		<variablelist>
			<varlistentry>
			<term><ulink
			url="news:comp.sys.powerpc.tech">comp.sys.powerpc.
			tech</ulink></term>
			<listitem>
			<para>PowerPC technical discussion</para>
			</listitem>
			</varlistentry>
			<varlistentry>
			<term><ulink
			url="news:comp.os.linux.embedded">comp.os.linux.
			embedded</ulink></term>
			<listitem>
			<para>General discussion of all flavours of
			embedded Linux</para>
			</listitem>
			</varlistentry>
			<varlistentry>
			<term><ulink
			url="news:comp.arch.embedded">comp.arch.embedded
			</ulink></term>
			<listitem>
			<para>General embedded system discussion</para>
			</listitem>
			</varlistentry>
		</variablelist>
	</sect2>

	<sect2>
		<title>Other Useful Resources</title>

		<para>Leif Lindholm's in-depth report on porting Linux
		2.2 to a custom MPC860 platform:
		<ulink
		url="http://www.realtimelogic.com/staff/leif/linux/linux_860_report.pdf.gz">http://www.realtimelogic.com/staff/leif/linux/
		linux_860_report.pdf.gz</ulink></para>

		<para>Matt Porter's Linux page: <ulink
		url="http://members.home.net/mmporter/linux/">http://members.
		home.net/mmporter/linux/</ulink></para>

		<para>LinuxPPC Solutions offered by DENX Software
		Engineering: <ulink
		url="http://www.denx.de/solutions-en.html">http://www.denx.
		de/solutions-en.html</ulink></para>

	</sect2>

</sect1>

<sect1>
	<title>Target Hardware</title>

	<para>Start by picking the processor which most closely
	matches your I/O requirements, and work out roughly how much
	RAM and ROM space you need. Then see if you can find an
	off-the-shelf board which also most closely matches what you
	need.
	</para>

	<sect2 id="cpus">
		<title>CPU</title>

		<sect3>
			<title>4xx</title>

			<para><ulink
			url="http://www.borg.umn.edu/~grant/Linux/">
			http://www.borg.umn.edu/~grant/Linux/</ulink>
			</para>

		</sect3>

		<sect3>
			<title>IBM 405GP</title>

			<para> <ulink
			url="http://www.mvista.com/news/2000/IBM_405.html">
			http://www.mvista.com/news/2000/IBM_405.html</ulink>,
			<ulink
			url="http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_405GP_Embedded_Processor">
			http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_405GP_Embedded_Processor
			</ulink>, and <ulink
			url="http://www.chips.ibm.com/products/powerpc/linux/">
			http://www.chips.ibm.com/products/powerpc/linux/</ulink>
			</para>

		</sect3>

		<sect3>
			<title>7xx</title>

			<para><ulink
			url="ftp://ftp.mvista.com/pub/Area51/ppc-7xx">
			ftp://ftp.mvista.com/pub/Area51/ppc-7xx</ulink>
			and <ulink
			url="http://www.chips.ibm.com/products/powerpc/linux/">
			http://www.chips.ibm.com/products/powerpc/linux/
			</ulink></para>

			<para>These devices are all covered in the
			MontaVista <link
			linkend="kernel">kernel</link>. </para>

		</sect3>
		<sect3>
			<title>Motorola 8xx</title>

			<para><ulink
			url="http://e-www.motorola.com/webapp/sps/prod_cat/sel_guide.jsp?catId=M98655">
			http://e-www.motorola.com/webapp/sps/prod_cat/sel_guide.jsp?catId=M98655
			</ulink>
			</para>

			<para>Information from Motorola is fragmented,
 			because the 850/860 and 823 are handled by
 			different groups. Information about the bits
 			they have in common is generally equally
 			applicable to both, so it's worth perusing the
 			823 resources even if you're using an
 			850/860. </para>

			<para>These devices are all covered in the
			<link linkend="kernel">MontaVista
			kernel</link>. </para>

			<sect4>
				<title>823</title>

				<para>See the 823 Engineer's Toolbox
				at: <ulink
				url="http://www.motorola.com/SPS/ADC/pps/subpgs/etoolbox/823/index.html">
				http://www.motorola.com/SPS/ADC/pps/subpgs/etoolbox/823/index.html
				</ulink></para>

			</sect4>

			<sect4>
				<title>850/855/860</title>

				<para><ulink
				url="http://www.motorola.com/SPS/RISC/cgi-bin/ncsp/ncsp.cgi">
				http://www.motorola.com/SPS/RISC/cgi-bin/ncsp/ncsp.cgi
				</ulink>
				</para>

			</sect4>

		</sect3>

		<sect3>
			<title>603e</title>

			<para>See: <ulink
			url="ftp://vlab1.iram.es/pub/linux-2.2/">
			ftp://vlab1.iram.es/pub/linux-2.2/</ulink></para>
		</sect3>

		<sect3>
			<title>Motorola 82xx</title>

			<para>See <ulink url="http://www.mvista.com/">
			http://www.mvista.com/</ulink></para>

			<sect4>
				<title>8240</title>

				<para>See <ulink
				url="ftp://ftp.mvista.com/pub/Area51/sandpoint-8240">
				ftp://ftp.mvista.com/pub/Area51/sandpoint-8240
				 </ulink></para>
			</sect4>

			<sect4>
				<title>8260</title>

				<para>See: <ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00123.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00123.html
				</ulink>
				and <ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200008/msg00107.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/200008/msg00107.html</ulink></para>
			</sect4>

		</sect3>

		<sect3>
			<title>AltiVec</title>
			<para>AltiVec is Motorola's answer to Intel's
			MMX. See <ulink url="http://www.altivec.com/">
			http://www.altivec.com/</ulink></para>

			<para>See <ulink
			url="ftp://ftp.mvista.com/pub/Area51/ppc-altivec">
			ftp://ftp.mvista.com/pub/Area51/ppc-altivec</ulink>
			</para>

		</sect3>

	</sect2>

	<sect2>
		<title>RAM and ROM space</title>

		<para>Linux has a slightly larger memory footprint
		than most conventional embedded operating systems when
		configured with equivalent options. This is the price
		you pay to leverage the advantages of its enormous
		desktop user base, and being able to share a common
		desktop and embedded environment. For most
		applications the difference is insignificant, but if
		every last byte counts in your application, you might
		want to consider <link linkend="RTEMs">RTEMs</link> or
		<link linkend="eCos">eCos</link> instead. </para>

		<para>Beware that commercial embedded operating system
		vendors often make meaningless claims regarding the
		footprint of their micro-kernel, and the total memory
		footprint (and often the royalties payable) increases
		substantially once all the optional packages needed to
		provide the required functionality for a typical
		networked device are included.  Work out what
		functionality you need before attempting to make valid
		comparisons.</para>

		<para>For good architectural reasons, Linux isn't a
		micro-kernel. However, it does allow large chunks of
		code to be removed easily at configuration time. In
		practice the architectural distinction between micro
		and monolithic kernels makes little difference to
		total memory requirements of the overall system.</para>

		<para>Minimum memory requirement when using an <link
		linkend="initrd">initrd</link> based <link
		linkend="root-filesystem">root filesystem</link> is
		generally 2 MB of flash ROM and 8 MB of RAM, and
		here's what you can expect to fit in:

		<itemizedlist>
			<listitem>
			<para><link linkend="ROM8xx">8xxROM</link>
			Monitor </para>
			</listitem>

			<listitem>
			<para>Linux-2.2.13 <link
			linkend="kernel">kernel</link></para>
			</listitem>

			<listitem>
			<para>minimal compressed <link
			linkend="initrd">initrd</link> <link
			linkend="root-filesystem">root
			filesystem</link> with /dev, /etc, /var and so
			forth.</para>
			</listitem>

			<listitem>
			<para>glibc-2.1.3 Shared C <link
			linkend="library">library</link>, including
			<link linkend="threads">pthreads
			support</link>.</para>
			</listitem>

			<listitem>
			<para>inetd Internet server</para>
			</listitem>

			<listitem><para>ftpd FTP server (for field
			flash ROM upgrades)</para>
			</listitem>

			<listitem><para>Medium sized Embedded C++
			application (~200 Kb)</para>
			</listitem>
		</itemizedlist>
		</para>
		
		<para>This is the most common configuration because it
		attempts to minimize ROM space at the expense of RAM,
		since ROM is generally more expensive. However, you
		can trade off ROM space to reduce RAM usage by using a
		compressed flash file system and/or running the kernel
		directly from ROM. Both these options are more
		difficult, but have been successfully deployed and
		discussed on the <link
		linkend="mail">&mailinglist;</link>.</para>

	</sect2>

	<sect2 id="boards">
		<title>Commercially available boards</title>
 
		<para>There are many off-the-shelf options including systems
		from Motorola and other parties. If you're planning on
		building your own custom hardware, consider using one
		of the Single Board Computer systems listed below
		instead. You might get by with just a custom daughter
		card, or might not need to do any hardware of your own
		at all.</para>

		<para>All the boards listed below are known to run
		Linux, although the degree of support can
		vary. Mention to the vendor that you want to run Linux
		on the board, and they should be able to point you to
		the relevant files you need. The best supported boards
		are supported directly in the main <link
		linkend="kernel"> kernel</link> development tree,
		which is most evident by having a dedicated <constant>
		_MACH_...</constant> constant already assigned in
		<filename>include/asm-ppc/processor.h</filename>.</para>

		<para>If you still think you want to do a full custom
		design, pick a board from one of the following sources
		with the closest feature match to what you plan to
		kick start your software development while your custom
		board is being designed and built:</para>

		<sect3>
			<title>Embedded Planet</title>

			<para><ulink
			url="http://www.embeddedplanet.com/">
			http://www.embeddedplanet.com/</ulink></para>

			<para>These boards are officially supported by
			the <link
			linkend="montavista">MontaVista</link>
			kernel. </para>

			<para>Use the new PlanetCore
			bootloader, as the old RPXU monitor times out
			on large tftp downloads.</para>

			<sect4 id="linuxplanet">
				<title>Linux Planet</title>

				<para>This is a complete development
				kit, including hardware and software.
				</para>
			</sect4>

			<sect4>
				<title>CLLF</title>

				<para>See: <ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199910/msg00055.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/199910/msg00055.html</ulink>
				</para>

				<para>CLLF-860T users should see:
				<ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00143.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00143.html
				</ulink></para>
			</sect4>

		</sect3>

		<sect3>
			<title>Bright Star Engineering</title>

			<para><ulink
			url="http://www.brightstareng.com/">
			http://www.brightstareng.com/</ulink></para>

			<para>Has an onboard <acronym>FPGA</acronym>
			for configuring hardware, making it extremely
			flexible for interfacing to exotic
			devices. They have a Linux development kit
			available for it too.</para>

			<para>If using a 2.2.x kernel, see: <ulink
			url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00088.html">
			http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00088.html</ulink></para>
		</sect3>

		<sect3 id="SNMC">
			<title>Simple Network Magic Corporation</title>

			<para><ulink url="http://www.snmc.com/">
			http://www.snmc.com/</ulink></para>
		</sect3>

		<sect3>
			<title>QS850 QuickStack Network
			Interface/Network Management Module</title>

			<para><ulink
			url="http://www.snmc.com/products.html">
			http://www.snmc.com/products.html</ulink></para>

			<para>The QS850 is a highly integrated and
			compact module for adding networking features
			to any embedded system. It provides a complete
			hardware and Linux-based software solution for
			Internet connectivity, Network Management, and
			Non-volatile File System services. See <link
			linkend="QSLinux">QSLinux</link>.</para>
		</sect3>

		<sect3 id="TQComponents">
			<title>TQComponents</title>

			<para><ulink url="http://www.tqc.de/">
			http://www.tqc.de/</ulink></para>

			<para>Have a range of very small mini-modules
			suitable for integration in a larger system,
			plus a starter kit for development. Supported
			by Denx Software Engineering, with pictures
			at: <ulink
			url="http://www.denx.de/embedded-ppc-en.html">
			http://www.denx.de/embedded-ppc-en.html</ulink>
			</para>

			<para>Also, see: <ulink
			url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199910/msg00088.html">
			http://lists.linuxppc.org/listarcs/linuxppc-
			embedded/199910/msg00088.html</ulink></para>
		</sect3>

		<sect3>
			<title>MicroSys</title>

			<para><ulink
			url="http://www.microsys.de/html/linux-e.html">
			http://www.microsys.de/html/linux-e.html</ulink>
			</para>

			<para>A VMEBus board vendor who now provides
			Linux ports for their boards.</para>

		</sect3>

		<sect3>
			<title>Motorola Computer Group</title>

			<para><ulink url="http://www.mcg.mot.com/">
			http://www.mcg.mot.com/</ulink></para>

			<sect4 id="MBX">
				<title>MBX</title>

				<para><ulink
				url="http://www.mcg.mot.com/cfm/templates/product.cfm?PageID=217&amp;ProductID=51&amp;PageTypeID=1">
				http://www.mcg.mot.com/cfm/templates/product.cfm?PageID=217&amp;ProductID=51&amp;PageTypeID=1
				</ulink>
				</para>

				<para>Before choosing this, see:
				<ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200010/msg00037.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/200010/msg00037.html
				</ulink></para>
			</sect4>

			<sect4>
				<title>PowerPlus SBC</title>

				<para><ulink
				url="http://members.home.net/mmporter/linux/">
				http://members.home.net/mmporter/linux/
				</ulink></para>
			</sect4>

			<sect4>
				<title>MVME2600</title>

				<para><ulink
				url="ftp://vlab1.iram.es/pub/linux-2.2/">
				ftp://vlab1.iram.es/pub/linux-2.2/</ulink>
				</para>
			</sect4>
		</sect3> 

		<sect3>
			<title>AG Electronics</title>

			<para><ulink
			url="http://www.agelectronics.co.uk/prod_ppc.html">
			http://www.agelectronics.co.uk/prod_ppc.html</ulink>
			</para>

			<para>A range of high-performance
			PowerPC-based products.</para>
		</sect3>

		<sect3>
			<title>Force Computers</title>

			<para><ulink
			url="http://www.forcecomputers.com/">
			http://www.forcecomputers.com/</ulink></para>

			<para>A range of high-performance
			PowerPC-based products.</para>
		</sect3>

		<sect3>
			<title>Actis Computer - VSBC-6862</title>

			<para><ulink
			url="http://www.actis-computer.com">
			http://www.actis-computer.com</ulink></para>

			<para>VSBC-6862 <ulink
			url="http://www.actis-computer.com/asp/vsbc6862.asp?adv=100">
			http://www.actis-computer.com/asp/vsbc6862.asp?adv=100</ulink>
			</para>

			<para>A VME based single board computer based
			on the Motorola MPC8260.</para>
		</sect3>

		<sect3>
			<title>Total Impact - the briQ</title>

			<para><ulink
			url="http://www.totalimpact.com/">
			http://www.totalimpact.com/</ulink></para>

			<para>The briQ is a PowerPC based network
			appliance computer the size of a standard
			CD-ROM drive targetted at a range of
			applications such as firewalls, routers,
			security devices and web servers. It is
			available with either a PowerPC 750 (G3) or
			7400 (G4) processor and can run any
			PowerPC-based Linux distribution available.</para>
		</sect3>

		<sect3>
			<title>Motorola Semiconductor</title>

			<sect4 id="FADS">
				<title>Family Application Development
				System</title>

				<para>Before you choose this one, see:
				<ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00007.html">
				http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00007.html
				</ulink></para>

				<para>Nevertheless, it is
				possible to use Linux PowerPC with
				(F)ADS.  Search for <ulink
				url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=FADS">
				FADS</ulink>. Also, see
				Solutions4Linux ADS/FADS 8xx: <ulink
				url="http://www.solutions4linux.de/powerpc.html"> 
				http://www.solutions4linux.de/powerpc.html
				</ulink></para>
			</sect4>

			<sect4>
				<title>Sandpoint</title>

				<para><ulink
				url="http://www.motorola.com/SPS/PowerPC/teksupport/refdesigns/sandpoint.html">
				http://www.motorola.com/SPS/PowerPC/teksupport/refdesigns/sandpoint.html
				</ulink>
				</para>

				<para>Contact <link
				linkend="montavista">MontaVista
				software</link>. </para>
			</sect4>

			<sect4>
				<title>Yellowknife</title>

				<para><ulink
				url="http://www.motorola.com/SPS/PowerPC/teksupport/refdesigns/yk.html">
				http://www.motorola.com/SPS/PowerPC/teksupport/refdesigns/yk.html
				</ulink>
				</para>

				<para>Contact <link
				linkend="montavista">MontaVista
				software </link>.</para>
			</sect4>

		</sect3>

		<sect3>
			<title>WindRiver (formerly EST Corporation)</title>

			<para><ulink url="http://www.windriver.com/products/html/embed_dev_tools.html">
			http://www.windriver.com/products/html/embed_dev_tools.html
			</ulink></para>

			<para>A number of development boards,
			including the MPC8260 based SBC8260.</para>

		</sect3>

		<sect3>
			<title>Haedong Information &
			Communications</title>

			<para><ulink url="http://www.headtel.com/">
			http://www.headtel.com/</ulink></para>

			<para>MPC860 Processor Modules.</para>

		</sect3>

		<sect3>
			<title>Cogent Computer Systems</title>

			<para><ulink url="http://www.cogcomp.com/">
			http://www.cogcomp.com/</ulink></para>

			<para>Modular development architecture
			including many varieties of PowerPC
			processor.</para>

		</sect3>
	</sect2>
</sect1>

<sect1>
	<title>Host Development Platform</title>

	<para>Embedded Linux's compelling advantage over other
	Embedded OS's is that your development host and target are the
	same. While you could theoretically develop your embedded
	Linux target system software on any host OS, Linux is the only
	sensible choice. Even Cygwin/UWIN is likely to waste more of
	your time.</para>

	<sect2>
		<title>PowerPC</title>

		<para>Using a PowerPC based development 
		host platform makes life easier, since the same
		binaries will run on your host and target. However, if
		your choice of host platform is restricted to
		non-PowerPC, cross compiling adds some minor
		inconvenience, primarily in finding or building your
		own toolset.</para>

		<para>You can take binaries from a standard
		PowerPC-based G4 Macintosh Linux distribution and run
		them unmodified on a PowerPC embedded system provided:
		<itemizedlist>
			<listitem>
			<para>The binaries are dynamically
			linked.</para>
			</listitem>
			<listitem>
			<para>You use the modified dynamic runtime
			<link linkend="glibc">glibc</link> C library,
			but compiled with
			<option>-mhard-float.</option></para>
			</listitem>
			<listitem>
			<para>You include the <link
			linkend="floating">floating point</link> math
			emulator in the kernel for processors such as
			the 8xx series that lack a real floating point
			unit.</para>
			</listitem>
		</itemizedlist>
		</para>

		<para>Note that for floating-point intensive
		applications this will invoke a performance penalty
		over re-compiling all the binaries and libraries; but
		recompiling is what you're trying to avoid, right?</para>

		<para>Also note that standard Macintosh binaries won't
		work with the runtime library in the <link
		linkend="hard-hat">Hard Hat</link> distribution on 8xx
		processors, because they've been compiled with
		<option>-msoft-float</option> to give optimum
		performance. In this case just use the equivalent Hard
		Hat binaries instead.</para>
	</sect2>

	<sect2>
		<title>x86</title>

		<para>There is a mini-howto intended for developers who 
                wish to build kernels and/or application on a Linux/x86 
                platform targeted for a Linux/PPC platform. Often this 
                is desirable if one has a faster x86 host system or the
                target environment is not practical to host a development
                environment
                <ulink url="http://penguinppc.org/embedded/cross-compiling/">
		http://penguinppc.org/embedded/cross-compiling/</ulink>.</para>


 		<para>Wolfgang Denk also has put together a document and
                scripts to build a PPC Cross Development Kit for MPC8xx CPUs.
                His objective was to build the cross development tools to 
                compile code for (embedded) PowerPC systems using Linux on 
                an Intel PC. The documents and scripts can be found at
                <ulink url="http://www.denx.de/cdk-en.html">
		http://www.denx.de/cdk-en.html</ulink>.</para>

	</sect2>

</sect1>

<sect1>
	<title>Compiler Toolset</title>

	<para>You'll need the GNU toolchain to compile the kernel,
	particularly <link linkend="gcc"><command>gcc</command></link>
	and <link
	linkend="binutils"><command>binutils</command></link>. As a
	general rule for working with GNU software, the latest
	official release is the best supported, has the most features
	and is usually the most stable. Also, you must use compatible
	versions, and there is generally no easy way to know which
	binutils version matches which arbitrary
	<command>gcc</command> version as their releases aren't
	synchronised. Hence, the best approach is generally to start
	by using the latest official release of any given package from
	your nearest GNU ftp site listed at <ulink
	url="http://www.gnu.org/order/ftp.html">http://www.gnu.org/order/
	ftp.html</ulink></para>

	<para>Many people use a particular version simply because they
	already have the source for it lying around, and waste a lot
	of time tracking down problems that were fixed by others
	months or even years ago. Grab the latest version at the
	outset, and you'll save an enormous amount of effort.</para>

	<para>If you need newer features that are not in an official
	release yet, you may need to move forward to the latest
	development snapshot from <ulink id="sources"
	url="http://sources.redhat.com/">http://sources.redhat.com</ulink>
	</para>

	<sect2>
		<title>Building the toolchain</title>

		<sect3>
			<title>Instructions</title>

			<para>A set of complete instructions for
			building a Cross Development system for
			Linux/PPC is available at: <ulink
			url="http://members.home.net/mmporter/linux/cross/">
			http://members.home.net/mmporter/linux/cross/
			</ulink></para>
		</sect3>

		<sect3>
			<title>Build Scripts</title>

			<para>For pre-packaged scripts to build a PPC
			Cross Development Kit for MPC8xx, see: <ulink
			url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CD-README">
			ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CD-README
			</ulink> and <ulink
			url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CDK.tar.gz">
			ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CDK.tar.gz
			</ulink></para>
		</sect3>

		<sect3>
			<title>SPARC/Solaris Hosted</title>

			<para>For a guide to building the
			PowerPC/Linux cross compiler for a
			SPARC/Solaris host (if you can't use a Linux
			development host), see: <ulink
			url="http://www.borg.umn.edu/~grant/Linux/cross.html">
			http://www.borg.umn.edu/~grant/Linux/cross.html
			</ulink></para>
		</sect3>

		<sect3>
			<title>Getting Help</title>

			<para>If you want to build a more exotic or
			unusual cross development environment, or need
			more help building the cross development
			tools, check out the crossgcc FAQ and mailing
			list at: <ulink
			url="http://www.objsw.com/CrossGCC/">
			http://www.objsw.com/CrossGCC/</ulink></para> 
		</sect3>

	</sect2>

	<sect2 id="gcc">
		<title>gcc</title>

		<para>Check that you have the latest gcc
		(2.95.2). Don't waste your time with any of the egcs
		releases as they've now been superseded by
		gcc.</para>

		<para>If you're using gcc-2.95.2 with
		binutils-2.9.1.0.25, you'll need a minor change to the
		gcc specs file regarding the linker emulation. You're
		better off just using binutils-2.10 though.</para>

	</sect2>

	<sect2 id="binutils">
		<title>binutils</title>

		<para>There are currently two branches of binutils
		development to choose from. Each have pro's and con's,
		and in many cases either one will work for you. They
		are typically referred to as the official "GNU
		binutils" and the "Linux binutils," although both are
		<link linkend="GPL">GPL'd</link> GNU software, and
		both versions configure, build, and work fine on
		Linux. I suggest you use the official GNU version,
		unless you encounter a problem which requires the
		"Linux binutils" version.</para>

		<sect3>
			<title>Official GNU binutils</title>

			<para>This tends to be the most stable
			version. The last release was 2.10, which is
			your best bet. It works well with gcc-2.95.2,
			whereas the 2.9.1 needed a tweak. If you must
			use the bleeding edge, the development
			snapshots on <ulink url="http://sources.redhat.com/">
			sources.redhat.com</ulink>are quite stable.</para>

			<para>The most recent snapshot is available at
			<ulink id="binutils-snap"
			url="ftp://sources.redhat.com/pub/binutils/snapshots/binutils.tar.bz2">
			ftp://sources.redhat.com/pub/binutils/snapshots/binutils.tar.bz
			</ulink></para>
		</sect3>

		<sect3>
			<title>H. J. Lu's "Linux binutils"</title>

			<para>At any given point in time, this version
			is based on recent official GNU development
			snapshot, but with more experimental features
			and hastily implemented bugfixes. It is
			shipped with many Linux
			distributions. However, the changes in this
			version aren't as thoroughly reviewed and
			tested as those in the official version, and
			the less well-implemented features probably
			won't make it back into the official GNU
			version, so it's a good idea not to rely on
			them. </para>

			<para>Version numbering is somewhat
			confusing. The Linux binutils 2.9.5.x versions
			are based on snapshots of the official
			development post 2.9.1. In particular, any
			given version of Linux binutils numbered
			2.9.5.x is not necessarily a later version
			than an official GNU development snapshot
			numbered 2.9.1.x.</para>

			<para>Beware that Linux binutils-2.9.5.0.27
			thru 29 will give you multiple definitions of
			<option>_dl_start</option> when building
			glibc-2.1.2. Try the official binutils-2.10
			instead, or Linux binutils-2.9.5.0.22.</para>
		</sect3>

	</sect2>

	<sect2>
		<title>Precompiled/Prepackaged Kits</title>

		<para>There are kits available which will save you the
		time of building your own tools, to get bootstrapped
		faster.</para>

		<sect3 id="montavista">
			<title>MontaVista Software Hard Hat
			Linux</title>
			<para><ulink url="http://www.mvista.com/">
			http://www.mvista.com/</ulink>
			</para>


			<para><ulink
			url="http://www.hardhatlinux.com/"
			id="hardhat">
			http://www.hardhatlinux.com/</ulink></para>

			<para>They have a complete 8xx
			cross-development kit described in <ulink
			url="ftp://ftp.mvista.com/pub/CDKit/1.2/README">
			ftp://ftp.mvista.com/pub/CDKit/1.2/README</ulink>
			available at: <ulink
			url="ftp://ftp.mvista.com/pub/CDKit/1.2/"
			id="hard-hat">ftp://ftp.mvista.com/pub/CDKit/1.2/</ulink>
			</para>

			<para>You can also purchase this kit as an
			integrated part of their Hard Hat Linux
			distribution and buy support for it directly
			from MontaVista.</para>

			<para>It's also available as part of the <link
			linkend="linuxplanet">Linux Planet</link> kit
			from Embedded Planet.</para>

		</sect3>

		<sect3 id="QSLinux">
			<title>QuickStack Linux</title>

			<para><ulink url="http://qslinux.com/">
			http://qslinux.com/</ulink></para>

			<para><ulink
			url="ftp://qslinux.com/pub/qslinux">
			ftp://qslinux.com/pub/qslinux</ulink></para>

			<para>This version of Linux is based on the PPC
			2.2.5 kernel. It has been heavily modified and
			targeted specifically to <link
			linkend="SNMC">SNMC</link>'s MPC850-based
			product. It includes:

			<itemizedlist>
				<listitem>
				<para>Subsystem for configuring
				and controlling I/O pins
				(<acronym>qspin</acronym>)</para>
				</listitem>
				<listitem>
				<para>Hardware Watchdog support</para>
				</listitem>
				<listitem>
				<para>Flash Filesystem (layered under
				Ext2FS)</para>
				</listitem>
				<listitem>
				<para>Compressed Ext2FS
				(<acronym>e2compr</acronym>)</para>
				</listitem>
				<listitem>
				<para><acronym>HDLC/PPP</acronym>
				Driver</para>
				</listitem>
				<listitem>
				<para><acronym>ATM</acronym> Utopia
				Network Driver (AAL5/IP)</para>
				</listitem>
				<listitem>
				<para>Multiple serial consoles</para>
				</listitem>
			</itemizedlist>
			</para>
		</sect3>

		<sect3 id="Denx">
			<title>Denx Software Engineering</title>

			<para><ulink
			url="http://www.denx.de/solutions-en.html">
			http://www.denx.de/solutions-en.html</ulink>
			</para>

			<sect4 id="Denx-ftp">
				<title>ftp site</title>

				<para><ulink
				url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/">
				ftp://ftp.denx.de/pub/LinuxPPC/usr/src/
				</ulink></para>
			</sect4>

			<sect4>
				<title>CD-ROMs</title>

				<para>Offer a CD-ROM with LinuxPPC for
				MPC8xx Systems, especially for <link
				linkend="TQComponents">TQM8xxL</link>
				Modules. It includes: 

				<itemizedlist>
					<listitem>
					<para>Sources and tools for a
					Cross Development Kit (CDK)
					for MPC8xx Embedded PowerPC
					Controllers on x86 Linux hosts
					</para>
					</listitem>
					<listitem>
					<para>Pre-built, ready-to-run
					binaries of the CDK</para>
					</listitem>
					<listitem>
					<para>Linux-2.2.13 kernel
					source tree for MPC8xx
					systems. There are also
					pre-built images for TQM8xxL
					modules.</para>
					</listitem> 
					<listitem>
					<para>Pre-installed native
					LinuxPPC root filesystem with
					all standard Linux tools to be
					exported on a NFS server and
					used as root filesystem for
					Embedded
					<acronym>PPC</acronym>
					systems.</para>
					</listitem> 
				</itemizedlist>

				</para>

			</sect4>

			<sect4>
				<title>Boards</title>

				<para>They also ship hardware with
				<link
				linkend="ppcboot"><command>PPCboot</command>
				</link>, <link
				linkend="kernel"><command>kernel</command>
				</link>, and <link
				linkend="root-filesystem">root
				filesystem </link>
				pre-installed. Just connect the power
				supply, and Linux is booting.</para>

			</sect4>
		</sect3>

		<sect3>
			<title>The Embedded Debian Project</title>

			<para><ulink url="http://www.emdebian.org/">
			http://www.emdebian.org/</ulink></para>

			<para>Debian project philosophy applied to the
			embedded space. Especially good for developers
			already running Debian on the desktop.</para>

		</sect3>

		<sect3>
			<title>Bright Star Engineering</title>

			<para><ulink
			url="http://www.brightstareng.com/">
			http://www.brightstareng.com</ulink></para>

			<para>You may get a kickstart by purchasing
			Bright Star's SDK, particularly if you're
			using one of their boards. For comments, see:
			<ulink
			url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00075.html">
			http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00075.html
			</ulink></para>

		</sect3>

		<sect3>
			<title>Lineo Embedix</title>
	
			<para><ulink
			url="http://www.lineo.com/">
			http://www.lineo.com/</ulink>
			</para>

                        <para>Lineo Embedix Linux is an embedded Linux-based
                        software solution that adds the power and connectivity
                        of Linux to customized embedded devices. Embedix Linux
                        is engineered specifically for the unique speed, memory
                        and storage requirements of embedded devices.</para>

			<para>Lineo provides embedded development kits for 
                        several PPC processors and boards. Additional
                        information can be found at:</para>

			<para>
                        <ulink url="http://www.lineo.com/products/embedix_sdk/white_paper.html">
			http://www.lineo.com/products/processors/embedix_sdk/white_paper.html</ulink>
                        and 
                        <ulink url="http://www.lineo.com/products/embedix_sdk/datasheet.html">
			http://www.lineo.com/products/embedix_sdk/datasheet.html</ulink>
			</para>

		</sect3>

		<sect3>
			<title>Red Hat Embedded DevKit</title>

			<para><ulink
			url="http://www.it.redhat.com/products/embedded/edk/">
			http://www.it.redhat.com/products/embedded/edk/</ulink></para>

			<para>Gets you started with embedded Linux
			development using Red Hat Linux. The box
			product includes a complete toolkit with IDE
			and ethernet-based debugging and supports
			development of PowerPC architecture systems,
			along with the x86 architecture.</para>

			<para>Oddly enough, the minimum target CPU
			required by the x86 binaries in the kit is a
			Pentium/586, whereas the minimum desktop CPU
			for Red Hat Linux is only a 386. Embedded
			systems most often have less powerful CPUs
			than desktop ones, not more powerfuld
			ones. This mistake doesn't affect PowerPC
			users at all, but you might want to consider
			whether this supplier is the best choice given
			such a fundamental error.</para>

		</sect3>

	</sect2>

</sect1>

<sect1>
	<title>Programming the Target</title>

	<para>Beware that many commercial tools will not handle the
	Linux zImage correctly. They often ignore the
	<systemitem>.image</systemitem> and
	<systemitem>.initrd</systemitem> sections (containing the
	compressed kernel and initial ram disk images respectively),
	because these sections aren't marked with the
	<varname>LOAD</varname> attribute. Whether this is a bug in
	the tools or in the zImage build process is debatable. Many
	developers avoid the problem by simply skipping the 64K ELF
	header, treating the rest as a binary image and jumping to the
	first byte to enter the kernel loader.</para>

	<para>If you want your debugger to have access to kernel
	symbols, use the conventional uncompressed <systemitem>vmlinux
	</systemitem> ELF image rather than
	<systemitem>zImage</systemitem>.</para>


	<sect2>
		<title>BDM/JTAG Downloading</title>

		<para>If your board is wired correctly, and you're
		using Flash memory, you can program it on your board
		using <firstterm>Background Debug Mode
		(BDM)</firstterm>, described later under <link
		linkend="gdb">Debugging</link>. BDM isn't the fastest
		method, but it's by far the easiest.</para>
	</sect2>

	<sect2>
		<title>TFTP</title>

		<para>If your ROM monitor supports <firstterm>Trivial File
		Transfer Protocol (TFTP)</firstterm>, this is the
		fastest and easiest way to download code to your
		target during development.</para>

		<para>A a program that will hack the headers
		such that the VxWorks TFTP loader would load the
		zImage is available at: <ulink
		url="ftp://ftp.mvista.com/pub/Area51/ppc-8xx/vxhack.c">
		ftp://ftp.mvista.com/pub/Area51/ppc-8xx/vxhack.c</ulink>
		</para>
	</sect2>

	<sect2>
		<title>Flash/EPROM Programmers</title>

		<para>You will need socketed flash to make this
		viable. There are sockets available even for surface
		mount flash devices which preserve the device
		footprint, but they consume extra space on your board,
		even when you go to production and leave them off.</para>

		<para>Some commercial EPROM programming units only
		support Windows, which may be a problem if you have
		access only to Linux machines.</para>

		<para>The Data I/O units have a terminal mode and an
		onboard floppy so they could be used from Linux
		without a problem.</para>

		<para>The general consensus is that anything with
		serial/parallel support and a DOS binary should be
		able to be used from DOSEMU. There are some options to
		allow direct parport access to RTFM on DOSEMU. VMWare
		hosting one of these should be no problem at all.</para>

		<para>Once you have a basic kernel booting on your
		board, you can use a <link linkend="flashdriver">flash
		driver</link> to reflash a new kernel quickly. You
		need to be confident that the new one will boot
		though, or have some alternative method of recovering
		if it doesn't, like socketed ROMs or a BDM flash
		programmer. </para>

	</sect2>

</sect1>

<sect1>
	<title>Boot Sequence</title>

	<para>The Linux boot sequence is more complicated than your
	average embedded operating system, and there are many more
	options for configuring things. In general, the boot sequence
	goes like this:
	<orderedlist>
		<listitem>
		<para>Processor comes out of reset and branches to the
		<link linkend="rom-monitor">ROM startup
		code</link>.</para>
		</listitem>
		<listitem>
		<para>The <link linkend="rom-monitor">ROM startup code
		</link> initializes the CPU and memory controller,
		performing only minimal initialization of on-chip
		devices, such as the console serial port (typically
		<link linkend="SMC">SMC1</link> on 8xx devices) to
		provide boot diagnostic messages. It also sets up the
		<link linkend="memory-map">memory map</link> for the
		<link linkend="kernel">kernel</link> to use in a
		format that is consistent across platforms, and then
		jumps to the <link linkend="bootloader">boot
		loader</link>.</para>
		</listitem>
		<listitem>
		<para>The <link linkend="bootloader">boot
		loader</link> decompresses the <link
		linkend="kernel">kernel</link> into RAM, and jumps to
		it. </para>
		</listitem>
		<listitem>
		<para>The <link linkend="kernel">kernel</link> sets up
		the caches, initializes each of the hardware devices
		via the <function>init</function> function in each
		driver, mounts the <link
		linkend="root-filesystem">root filesystem</link> and
		execs the <function>init</function> process, which is the
		ultimate parent of all user mode processes, typically
		<filename>/sbin/initd</filename>.</para>
		</listitem>
		<listitem>
		<para>Executing the first program linked against the
		shared <link linkend="library">C runtime
		library</link> (often <function>init</function>)
		causes the shared runtime library to be loaded.</para>
		</listitem>
		<listitem>
		<para>In a typical Linux system,
		<function>init</function> reads <filename>/etc/inittab
		</filename> to execute the appropriate run control
		script from <filename>/etc/rc.d</filename>, which
		execute the start scripts to initialize networking and
		other system services.</para>
		</listitem>
	</orderedlist>
	</para>

	<para>In minimal embedded systems, <function>init</function>
	is commonly replaced with a simple C program or shell script
	to start the appropriate services and <link
	linkend="applications">application programs</link>, since the
	conventional rc scripts are often overkill.</para>

</sect1>

<sect1 id="rom-monitor">
	<title>ROM Monitor</title>

	<para>If you're using custom hardware, you'll need a ROM
	monitor to help bring it up. A monitor generally provides a
	simple command prompt, with options for reading/writing memory
	and perhaps some power-on testing facilities which are useful
	before the kernel boots.</para>

	<para>ROM monitors invariably include <link
	linkend="bootloader">boot loader</link> functionality, but if
	your device goes into production you may want a standalone
	boot loader or a stripped-down ROM monitor. There are several
	available on the net:</para>

	<sect2 ID="ppcboot">
		<title>PPCBOOT</title>

		<para><ulink url="http://ppcboot.sourceforge.net/">
		http://ppcboot.sourceforge.net/</ulink></para>

		<para>This is an actively developed ROM monitor and
		Linux boot loader ideal for custom boards, derived
		from 8xxROM and FADSROM. It includes support for
		BOOTP, RARP and TFTP image downloading and booting. </para>
	</sect2>

	<sect2>
		<title>LiMon</title>

		<para><ulink url="http://www.thinsys.com/limon.html">
		http://www.thinsys.com/limon.html</ulink></para>

		<para>The Linux Monitor (LiMon) is a low level system	
		start utility for the SBC8260. It also includes BOOTP
		and TFTP support.</para>
	</sect2>

	<sect2>
		<title>PMON/2000</title>

		<para><ulink url="http://pmon.groupbsd.org/">
		http://pmon.groupbsd.org/</ulink></para>

		<para>The PMON/2000 BootROM Monitor (PMON/2000)
		permits full-featured debugging to be performed on a
		target board that has a serial port, 512KB of ROM, and
		128KB of RAM that can be dedicated to the Prom Monitor
		software.</para>
	</sect2>

	<sect2>
		<title>PPCForth</title>

		<para><ulink url="http://ppcforth.sourceforge.net/">
		http://ppcforth.sourceforge.net/</ulink></para>

		<para>It is currently targeted for the IBM 403, 8xx is
		a goal for the future. It is ROM-able so you can boot
		directly from it, and has some ifdef's to slim the
		code down to as little as 10K or as large as 30K. It
		accepts S records over the serial port for loading
		other software. Unfortunately it is written in
		assembly, but then it's really small and is released
		under the <link linkend="GPL">GPL</link>. It is a
		small implementation of FORTH which is handy for
		testing and small programs, although the author went
		overboard and included multitasking and a lot of
		low-level device control words.</para>

	</sect2>


	<sect2>
		<title>DINK32</title>

		<para><ulink
		url="http://www.mot.com/SPS/PowerPC/teksupport/tools/DINK32/VERSION12/dinkindex.htm">
		http://www.mot.com/SPS/PowerPC/teksupport/tools/DINK32/VERSION12/dinkindex.htm
		</ulink></para>

		<para>DINK32 was developed as an internal Motorola 
		PowerPC tool to help debug silicon as well as code.
		It runs on a variety of boards including the Yellowknife,
		Sandpoint, Excimer and Maximer. DINK32 has the full 
		complement of commands. DINK32 supports all of the 
		currently available PowerPC microprocessors including the
		603, 603e, 604 family, the integrated processor, 8200 the
		8240, the 7xx family and the 7400. DINK32 is a great source
		for example code when initializing the MPC105, MPC106, MPC107
		memory controllers/bridge chips. DINK32 source code also 
		includes sample code for the MPC8240 subsystems, DMA, EPIC,
		I2C, and I2O. </para>



	</sect2>

	<sect2 id="ROM8xx">
		<title>8xxROM</title>

		<para><ulink url="http://www.s4l.de/powerpc.html">
		http://www.s4l.de/powerpc.html</ulink></para>

		<para>Derived from FADSROM. No longer actively
		developed, and only really of historical interest as
		it has been superseded by <link
		linkend="ppcboot">ppcboot</link>.</para>
	</sect2>

	<sect2 id="fadsrom">
		<title>FADSROM</title>

		<para>An old ROM monitor and loader written for the
		<link linkend="FADS">FADS</link> board: <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00045.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00045.html
		</ulink></para>

		<para>FADSROM has been superseded by <link
		linkend="ppcboot">ppcboot</link>.</para>
	</sect2>

</sect1>

<sect1 id="bootloader">
	<title>Boot Loader</title>

	<para>If you're using custom hardware, or want to replace the
	ROM monitor on your board, you'll need a boot loader that
	knows how to decompress and transfer control to the
	kernel. The current trend is to include this functionality in
	the <link linkend="rom-monitor">ROM monitor</link>, as is the
	case with <link linkend="ppcboot">ppcboot</link>.</para>

	<para>Although some of the data is board specific, you can
	assemble the bits from information available on the net: <ulink
	url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199911/msg00034.html">
	http://lists.linuxppc.org/listarcs/linuxppc-embedded/199911/msg00034.html
	</ulink></para>

	<sect2>
		<title>bugboot</title>

		<para>For PreP and PowerPlus SBC's, see:

		<itemizedlist>
		<listitem>
		<para><ulink url="http://members.home.net/mmporter/linux/">
		http://members.home.net/mmporter/linux/</ulink></para>
		</listitem>
		<listitem>
		<para><ulink
		url="http://members.home.net/mmporter/linux/linuxppc/preploader.tgz">
		http://members.home.net/mmporter/linux/
		linuxppc/preploader.tgz</ulink></para>
		</listitem>
		<listitem>
		<para><ulink
		url="http://members.home.net/mmporter/linux/linuxppc/bugboot-0.3.tar.gz">
		http://members.home.net/mmporter/linux/
		linuxppc/bugboot-0.3.tar.gz</ulink></para>
		</listitem>
		</itemizedlist>
		</para>
	</sect2>

	<sect2>
		<title>mbxboot</title>

		<para>The old bootloader included in the kernel source
		tree, originally written for the <link
		linkend="MBX">Motorola MBX</link> board, and since
		ported to a wide range of platforms. This is the
		start-up component of the
		<systemitem>zImage</systemitem> that knows how to
		decompress the kernel.
		<application>mbxboot</application> is now
		being rendered obsolete by <link linkend="ppcboot">
		<application>ppcboot</application></link>.</para>

	</sect2>

</sect1>

<sect1 id="kernel">
	<title>Kernel</title>

	<sect2>
		<title>Series</title>

		<para>You will need to decide whether to use a
		tried-and-tested, stable series kernel, or a
		development kernel. The choice will depend on your
		project requirements and how much work you want to do
		to port and maintain the kernel on your hardware. For
		any non-trivial project, you can expect several major
		kernel releases during the project's life. Consider
		the availability of the features you need, how leading
		edge you want to be, and the likely status of each
		kernel series by the time you're ready to ship.</para>

		<para>You are probably best off using the stable
		version, unless you want to actively participate in
		future development of Linux itself, or require
		features or board support only present in the
		development series.</para>

		<sect3>
			<title>Stable</title>

			<sect4>
				<title>Montavista</title>

				<para>The latest stable kernel from
				the MontaVista <link
				linkend="hard-hat">Hard Hat
				Linux</link> kit is probably your best
				bet.</para>

				<para>Also, check for later updates
				in <ulink
				url="ftp://ftp.mvista.com/pub/CDKit/updates/">
				ftp://ftp.mvista.com/pub/CDKit/updates/</ulink>
				</para>

				<para>For the very latest
				work-in-progress, see: <ulink
				url="ftp://ftp.mvista.com/pub/CDKit/wip/ppc_8xx/RPMS">
				ftp://ftp.mvista.com/pub/
				CDKit/wip/ppc_8xx/RPMS</ulink></para>
			</sect4>

			<sect4>
				<title>Denx Software Engineering</title>

				<para><ulink
				url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/">
				ftp://ftp.denx.de/pub/LinuxPPC/usr/src/
				</ulink></para>
			</sect4>

		</sect3>

		<sect3>
			<title>Development</title>

			<para><ulink
				url="http://www.kernel.org/">
				http://www.kernel.org/</ulink> and
				<ulink
				url="http://penguinppc.org">
				http://penguinppc.org</ulink></para>

				<para>Work is ongoing to merge the
				embedded PowerPC changes into the
				current development tree, but the
				latest PPC changes take some time to
				propagate here.</para>
			
		</sect3>

	</sect2>

	<sect2 id="memory-map">
		<title>Memory Map</title>


		<para>The <link linkend="bootloader">boot
		loader</link> is responsible for configuring the
		memory map before jumping to the Linux
		kernel. Embedded PowerPC processors provide extreme
		flexibility for address mapping of internal and
		external devices. You should use this flexibitily to
		configure the memory map of your board to match the
		needs of the Linux kernel, rather than modify the
		Linux kernel <link
		linkend="MMU"><acronym>MMU</acronym></link> handling
		to match some arbitrary addressing scheme.</para>

		<para>See: <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00157.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00157.html</ulink></para>

		<para>also check out
		<filename>Documentation/IO-mapping.txt</filename> in
		the kernel source tree.</para>
	</sect2>
	
	<sect2>
		<title>Porting</title>

		<para>Provided that the <link
		linkend="cpus">CPU</link> you are using is already
		supported in the kernel, most of the work involved in
		porting Linux to a new platform actually involves
		changes to the <link linkend="rom-monitor">ROM
		startup</link> code, rather than the kernel
		itself. The other major kernel effort required is in
		<link linkend="device-drivers">device drivers</link>
		for new hardware devices.</para>

	</sect2>

	<sect2>
		<title>Patches</title>

		<para>Once you've got something working, there's an
		abundance of kernel patches available on the Internet
		which can help customize the kernel to your
		application. Patches are generally issued against a
		particular kernel version, but can often be applied
		against other versions either automatically or with
		manual assistance. The latest patches are usually
		available from the &mailinglist;.</para>

		<para>Peter Allworth has some kernel patches at <ulink
		url="http://www.zeta.org.au/~linsol/">http://www.zeta.org.au/
		~linsol/</ulink></para>

	</sect2>

	<sect2>
		<title>Contributing</title>

		<para>The people who actively contribute to open
		source development are also the ones who benefit the
		most from it, so it makes sense to actively contribute
		wherever you can.</para>

		<para>Virtually all the existing embedded Linux code
		is covered by the <link
		linkend="GPL"><acronym>GPL</acronym></link>, which
		requires you to redistribute any changes you make.
		Contributing your work offers an invaluable
		opportunity for peer review far beyond what is
		normally possible within a single organization and can
		save countless hours of unnecessary debugging.</para>

	</sect2>

	<sect2>
		<title>Submitting Patches</title>

		<para>In general, patches should be submitted in
		unidiff format to the <link linkend="mail">mailing
		list</link>. Even if you submit them directly to the
		maintainer, remember to cc: a copy to the mailing
		list, to keep everyone else informed of what's going
		on. If it's large, put it up for ftp and post a
		pointer instead.</para>

	</sect2>

	<sect2>
		<title>Coding Style</title>

		<para>When working on an existing code base, you
		should always use whatever coding style is used in the
		existing code. Consistency here is better than your
		subjective notion of correctness.</para>

		<para>When working on the kernel, follow the
		guidelines in
		<filename>Documentation/CodingStyle</filename>.</para>

		<para>When working on other GNU software, follow the
		guidelines at <ulink
		url="http://www.gnu.org/prep/standards_toc.html">http://www.gnu.org/prep/standards_toc.html
		</ulink></para>

	</sect2>

</sect1>

<sect1 id="device-drivers">
	<title>Device Drivers</title>

	<para>The kernel already includes device drivers for the
	on-chip serial and ethernet ports.</para>

	<sect2>
		<title>Examples</title>

		<para>For helpful MPC8xx-specific device driver
		examples, see <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00221.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00221.html
		</ulink></para>

		<para><ulink
		url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/drivers.tar.gz">
		ftp://ftp.denx.de/pub/LinuxPPC/usr/src/drivers.tar.gz</ulink>
		</para>
	</sect2>

	<sect2 id="flashdriver">
		<title>Flash memory</title>

		<sect3>
			<title>Flash Device Driver</title>

			<para><ulink
			url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CDK.tar.gz">
			ftp://ftp.denx.de/pub/LinuxPPC/usr/src/CDK.tar.gz
			</ulink></para>

			<para>A flash driver will give you access to
			<filename>/dev/flash</filename> devices, which
			are useful during development and for field
			upgrades and are ideal for storing fixed size
			persistent configuration data like your
			board's Ethernet MAC address. This is true for 
			drivers supporting a number of vendors'
			devices. </para>

			<para>The flash driver does auto-erase when
			the length of data written per
			<command>write()</command> is exactly the
			corresponding erase block size. So usually you
			just need to do:
			<programlisting>
open (/dev/flash???)
lseek(specific erase region)
write(data, region size)
			</programlisting></para>

		</sect3>

		<sect3>
			<title>QSLinux Flash Driver</title>

			<para><ulink
			url="http://qslinux.org">http://qslinux.org</ulink>
			and <ulink
			url="ftp://qslinux.org">ftp://qslinux.org</ulink>
			</para>

			<para>QSLinux contains a fully functioning
			FLASH driver, and an interface to the Ext2FS
			filesystem, with compression.</para>
		</sect3>

		<sect3 id="mtd">
			<title>Memory Technology Device (MTD) Subsystem</title>

			<para><ulink
			url="http://www.linux-mtd.infradead.org/">
			http://www.linux-mtd.infradead.org/</ulink></para>

			<para>The MTD subsystem offers a more general
			solution which allows you to treat the flash
			as a regular block device on which you can
			mount a filesystem. It's ideal for large
			amounts of variable sized data or applications
			requiring a traditional writable filesystem,
			provided by the <link
			linkend="jffs">Journaling Flash
			Filesystem</link>. </para>

			<para>However, some work is required to get
			the MTD to run on PowerPC, as it does not yet
			support big endian. </para>

		</sect3>

		<sect3>
			<title>M-Systems Disk-On-Chip</title>

			<para><ulink
			url="http://www.linux-mtd.infradead.org/doc2000.html">
			http://www.linux-mtd.infradead.org/doc2000.html
			</ulink></para>

			<para>This is supported via the <link
			linkend="mtd">Memory Technology Device</link>
			Subsystem.</para>
		</sect3> 

	</sect2>

	<sect2>
		<title>PCMCIA Cards</title>

		<para>For a PCMCIA driver, see <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00093.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00093.html
		</ulink></para>

		<para>There are also some fairly detailed notes
		available at <ulink
		url="ftp://ftp.absoval.com/pub/rpxlite/">
		ftp://ftp.absoval.com/pub/rpxlite/</ulink> and <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00227.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00227.html
		</ulink></para>

		<para>For generic Linux PCMCIA info, see <ulink
		url="http://pcmcia.sourceforge.org/ftp/doc/PCMCIA-PROG.html">
		http://pcmcia.sourceforge.org/ftp/doc/PCMCIA-PROG.html</ulink>
		</para>
	</sect2>

	<sect2>
		<title>IDE/ATA Disk Drives</title>

		<para>There are lots of options for connecting IDE
		drives. You need to at least configure
		CONFIG_BLK_DEV_IDE and CONFIG_BLK_DEV_IDEDISK. Search
		for <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=IDE">
		IDE</ulink>.</para>

		<para>Also, see <ulink
		url="http://www.bluebutton.com/proj/mbxlinux/">
		http://www.bluebutton.com/proj/mbxlinux/</ulink></para>

	</sect2>

	<sect2>
		<title>PCI Bridge</title>

		<para>Search for <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=QSPAN">
		QSPAN</ulink> or <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=PowerSpan">
		PowerSpan</ulink>.</para>

	</sect2>

	<sect2>
		<title>Watchdog</title>

		<para>Using the on-chip watchdog to provide the basic
		"write kicked" <filename>/dev/watchdog</filename>
		interface described in
		<filename>Documentation/watchdog.txt</filename> is
		problematic, because the SYPCR register controlling it
		can only be written once after reset to both set the
		timeout and enable the watchdog. Once enabled, the
		boot loader and kernel must keep it from expiring up
		until the point where the user application opens
		<filename>/dev/watchdog</filename>. Littering the
		generic kernel decompress and startup codes with
		watchdog kicks to do this isn't acceptable to other
		Linux users. Hence, hardware watchdog support hasn't
		been implemented yet.</para>

		<para>The general plan to solve this problem is
		described in <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199910/msg00026.html">
		http://lists.linuxppc.org/listarcs/
		linuxppc-embedded/199910/msg00026.html</ulink></para>

		<para>You can probably use Linux's software watchdog
		in the meantime.</para>
	</sect2>

	<sect2>
		<title>USB for MPC850/823</title>

		<para><ulink url="http://www.honeywell.se/inu/usb/">
		http://www.honeywell.se/inu/usb/</ulink></para>

		<para>These devices can be made to operate as a USB
		host or slave. Search for <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=USB">
		USB</ulink>.</para>

		<para>Also see the Programming Guide for Linux USB
		Device Drivers at <ulink
		url="http://usb.in.tum.de/usbdoc/">http://usb.in.tum.de/
		usbdoc/</ulink></para>

	</sect2>

	<sect2>
		<title>A/D and D/A</title>

		<para>Use something that "frames" the data and the
		SI/TDM interface works really sweet. Take a look at
		the CS4218 audio codec driver for the Embedded Planet
		boards.  It's floating around in the 2.2.13 kernels on
		the MontaVista site.</para>

	</sect2>

	<sect2>
		<title>VME</title>

		<para>Numerous VME <link linkend="boards">board
		vendors</link> offer Linux support through software
		partners such as <link linkend="Denx">Denx</link>.</para>

		<para>Some older patches and tarballs to use Linux on
		VME boards and simplify the access to the VME bus are
		available at <ulink
		url="ftp://vlab1.iram.es/pub/linux-vme/">ftp://vlab1.iram.es/
		pub/linux-vme/</ulink></para>
	</sect2>

	<sect2>
		<title>HDLC/PPP</title>

		<para><ulink
		url="http://qslinux.org/docs/snmc/hdlc/index.html">http://qslinux.org/docs/snmc/hdlc/index.html
		</ulink></para>

		<para>Provides support for the HDLC protocol, running
		the PPP layer in order to transport IP packets across
		a synchronous serial link.</para>

	</sect2>

	<sect2>
		<title>SPI</title>

		<para><ulink url="ftp://216.118.31.75/pub/">
		ftp://216.118.31.75/pub/</ulink></para>

		<para>This driver is an interface for the <link
		linkend="SPI">SPI</link> controller in MPC8xx. The
		driver is written to work with the microcode patches
		to correct the parameter RAM problems. The driver
		supports basic <function>init</function>,
		<function>open</function>, <function>close</function>,
		<function>read</function>, and
		<function>write</function> functions.</para>
	</sect2>

	<sect2>
		<title>Linux STREAMS (LiS)</title>

		<para><ulink url="http://www.gcom.com/home/linux/lis/">
		http://www.gcom.com/home/linux/lis/</ulink></para>

		<para>LiS is a software package that comprises an
		implementation of SVR4-compatible STREAMS for Linux in
		the form of a loadable kernel module.</para>

		<para>A patch to port it to MPC8xx based Embedded
		PowerPC systems is available at <ulink
		url="ftp://ftp.denx.de/pub/LinuxPPC/usr/src/LiS/">
		ftp://ftp.denx.de/pub/LinuxPPC/usr/src/LiS/</ulink></para>

	</sect2>

</sect1>

<sect1 id="library">
	<title>Runtime Library</title>

	<sect2 id="glibc">
		<title>glibc</title>

		<para><ulink url="http://www.gnu.org/software/libc/">
		http://www.gnu.org/software/libc/</ulink> and <ulink
		url="http://sources.redhat.com/glibc/">
		http://sources.redhat.com/glibc/</ulink></para>

		<para>Modern releases of glibc are very large for a
		traditional embedded system. If your application
		requires only one or two user programs, you can
		statically link them to avoid requiring the entire
		dynamic library. Another option is to hand-strip the
		dynamic library to a bare minimum. </para>

		<para>Some modifications are required to the official
		glibc-2.1.x releases to make them work in the embedded
		PowerPC environment, such as cache line size
		modifications.  See<ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html
		</ulink></para>

		<para>After applying these modifications, glibc-2.1.x can be
		configured for cross-compiling with:
			<programlisting>
    #!/bin/sh
    export PATH=/path/to/local/i686-pc-linux-gnu/bin:$PATH
    export CFLAGS="-msoft-float -O2 -DNDEBUG=1"
    export CC=powerpc-linux-gcc
    export AR=powerpc-linux-ar
    export RANLIB=powerpc-linux-ranlib
    configure --host=powerpc-linux --prefix=/path/to/local/powerpc-linux \
    --with-headers=/path/to/linux-2.2.13/include --enable-add-ons=linuxthreads \
    --with-gnu-as --with-gnu-ld --disable-sanity-checks --without-fp
			</programlisting>
		</para>

		<para>There is a magic script named
		<filename>mklibs.sh</filename> which removes unused
		functions from the shared C library in the Debian Boot
		Floppies package, at <ulink
		url="ftp://ftp.us.debian.org/debian/dists/potato/main/source/admin/boot-floppies_2.2.23.tar.gz">
		ftp://ftp.us.debian.org/debian/dists/potato/main/source/admin/boot-floppies_2.2.23.tar.gz
		</ulink></para>

	</sect2>

	<sect2>
		<title>sglibc</title>

		<para><ulink
		url="http://sourceforge.net/projects/sglibc">
		http://sourceforge.net/projects/sglibc</ulink> and
		<ulink
		url="http://external-lists.varesearch.com/lists/listinfo/sglibc">
		http://external-lists.varesearch.com/lists/listinfo/sglibc
		</ulink></para>

		<para>This is an attempt to produce a small
		glibc-compatible C runtime library subset suitable for
		embedded systems.</para>

		<para>To cut down some of the bloat in glibc, apply
		the patches at <ulink
		url="http://external-lists.varesearch.com/archives/sglibc/1999-September/000007.html">
		http://external-lists.varesearch.com/archives/sglibc/1999-September/000007.html
		</ulink></para>

	</sect2>

	<sect2>
		<title>uClibc</title>

		<para><ulink
		url="http://opensource.lineo.com/cgi-bin/cvsweb/uClibc/">
		http://opensource.lineo.com/cgi-bin/cvsweb/uClibc/</ulink>
		</para>

		<para>uC-Libc is a C library for embedded systems
		developed originally for uClinux and now being ported
		to other architectures including PowerPC. It has a
		different set of design goals from GNU libc, but for
		many embedded systems it is a sensible choice.</para>
	</sect2>

	<sect2>
		<title>dietlibc</title>

		<para><ulink url="http://www.fefe.de/dietlibc/">
		http://www.fefe.de/dietlibc/</ulink></para>

		<para>The diet libc is a libc that is optimized for 
		small size. It can be used to create small statically
		linked binaries for Linux on alpha, arm, mips, sparc,
		ppc and x86.</para>

	</sect2>

	<sect2>
		<title>newlib</title>

		<para><ulink url="http://sources.redhat.com/newlib/">
		http://sources.redhat.com/newlib/</ulink></para>

		<para>Newlib is a free C library intended for use on
		embedded systems, with less restrictive licensing than
		the <link linkend="GPL">GPL</link>. However, it
		currently lacks the libgloss layer necessary to use it
		as the C library under Linux.</para>
	</sect2>

	<sect2>
		<title>libc5</title>
		
		<para>Older Linux libc's are often quite small, but
		generally not supported by anyone now.</para>

	</sect2>

</sect1>

<sect1 id="root-filesystem">
	<title>Root Filesystem</title>

	<para>The kernel needs a root filesystem to mount at startup.
	There are many options, and the best one will
	generally depend on whether your system needs to be able to
	store persistent data (which must survive power cycling) in
	the field.</para>

	<para>See <ulink
	url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200003/msg00067.html">
	http://lists.linuxppc.org/listarcs/linuxppc-embedded/
	200003/msg00067.html</ulink></para>

	<para>Your best bet is likely to be the root filesystem from
	<link linkend="hard-hat">Hard Hat Linux</link>. Extract all
	the RPMs matching <filename>*.noarch.rpm</filename>, and use
	the image in
	<filename>opt/hardhat/devkit/ppc/8xx/target</filename> as the
	root filesystem.</para>

	<sect2>
		<title>NFS Mounted</title>

		<para>During development, the embedded system can
		NFS-mount its root filesystem from your file sever to
		provide a complete diskless Linux system. The file
		server need not be the same architecture as the
		embedded client. Answer "Y" to the kernel
		configuration questions regarding NFS client and root
		filesystem via NFS, and "make zImage". The embedded
		system will attempt to mount its root filesystem from
		the server as
		<filename>/tftpboot/&lt;ipaddress&gt;</filename>,
		where &lt;ipaddress&gt; is its IP address. Install
		your root filesystem image in this directory as root
		on the server, and export the directory tree with an
		entry in <filename>/etc/exports</filename> on the
		server, like:

		<programlisting>
    /tftpboot   (rw,no_root_squash)
		</programlisting>
		</para>

		<para>If your system has a hard disk, you can start by
		using NFS then build a root file system on the disk
		and boot from that.</para>

		<para>If your system has no network, you may want to
		start developing on a board that does.</para>
	</sect2>

	<sect2 id="initrd">
		<title>Initial Ramdisk: initrd</title>

		<para>To make a diskless system standalone, you need
		an initial ramdisk image containing an ext2 filesystem
		to put in
		<filename>arch/ppc/mbxboot/ramdisk.image.gz</filename>.
		Then, build with <filename>make
		zImage.initrd</filename> and the ramdisk image will be
		mounted as the root filesystem at startup. See
		<filename>Documentation/initrd.txt</filename> in the
		kernel source tree.</para>

		<para>You need to select both CONFIG_BLK_DEV_RAM and
		CONFIG_BLK_DEV_INITRD to build zImage.initrd. You also
		need a file in <filename>arch/ppc/mbxboot</filename>
		called <filename>ramdisk.image.gz</filename>. When you
		build <filename>zImage.initrd</filename>, the
		secondary boot loader is re-compiled with
		INITRD_OFFSET and INITRD_SIZE set, which are used to
		locate the start and end of the
		<filename>ramdisk.image.gz</filename> file in
		memory. The start and end are passed to the kernel in
		registers (r4/r5??), which it saves into the variables
		<varname>initrd_start</varname> and
		<varname>initrd_end</varname>. The secondary boot
		loader also changes the kernel command line arguments
		so that 
			<programlisting>
	root=/dev/ram
			</programlisting> instead of
			<programlisting>
	root=/dev/nfs
			</programlisting>
		</para>

		<para>The kernel does various things if
		<varname>initrd_start</varname> is non-zero, but the
		main one is to decompress the
		<filename>ramdisk.image.gz</filename> data into
		ramdisk 0, and because 
			<programlisting>
	root=/dev/ram
			</programlisting>this is then mounted as the
			root filesystem.</para>

		<para>If your ramdisk is larger than 4 MB, you will
		need to add 
			<programlisting>
	ramdisk=xxxx
			</programlisting>to the kernel command line at
			boot time, or modify
			<filename>drivers/block/rd.c</filename>.</para>

		<para>Beware that the CPU6 workarounds in the
		MontaVista 2.2.x kernel clobber the kernel command
		line, and cause the initial ramdisk mount to fail. See
		the thread at <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200004/msg00103.html">
		http://lists.linuxppc.org/listarcs/
		linuxppc-embedded/200004/msg00103.html</ulink></para>

		<para>A number of ways to create an initial ramdisk
		image are described below. For more information on
		building a root filesystem, see the Bootdisk HOWTO at
		<ulink
		url="http://www.linux.org/docs/ldp/howto/Bootdisk-HOWTO/buildroot.html">
		http://www.linux.org/docs/ldp/howto/
		Bootdisk-HOWTO/buildroot.html</ulink></para>

		<sect3>
			<title>Examples</title>

			<para>An example
			<filename>ramdisk.image.gz</filename> is
			already included in the <link
			linkend="hard-hat">Hard Hat</link> kit.</para>

			<para>A simple ramdisk for use with <link
			linkend="ppcboot">ppcboot</link> is available
			at the <link linkend="Denx-ftp">Denx ftp
			site</link>.</para>
		</sect3>

		<sect3>
			<title>Using a ramdisk</title>

			<para>You can also create your own on your
			development machine in a filesystem on
			<filename>/dev/ram</filename>. If your ramdisk
			is larger than 4 MB, you will need to increase
			the default ramdisk size on your development
			machine accordingly.</para>

			<para>LILO users can do this by adding the
			following line to the first section of
			<filename>/etc/lilo.conf</filename>:

				<programlisting>
	ramdisk=65536
				</programlisting>
			</para>

			<para>There is no real harm in asking for an
			excessive size, as
			<filename>/dev/ram*</filename> only allocates
			pages it actually needs to the
			ramdisk. However, you should use the
			<parameter>blocks-count</parameter> parameter
			to limit the filesystem size when you run
			<command>mke2fs</command> to prevent it
			creating unnecessarily large filesystem
			structures.</para>
		</sect3>

		<sect3>
			<title>Using the loop device</title>

			<para>Another approach is to use the loop
			device on your Linux development host to mount
			the ramdisk image as a local filesystem, and
			then copy the files you require into it. To
			allow users to mount the
			<filename>ramdisk.image</filename> on
			<filename>/mnt/loop</filename> with 
				<programlisting>
mount /mnt/loop
				</programlisting> add the following
				entry to your
				<filename>/etc/fstab</filename>: 
				<programlisting>
/path/to/ramdisk.image  /mnt/loop       auto    user,noauto,rw,loop     0 0
				</programlisting>
			</para>

			<para>Note that the minix file system code in
			Linux is not endian-independant, so you can't
			build a minix file system image on an x86
			machine and expect to read it on a PowerPC
			machine. ext2 does not suffer from this
			problem. </para>

			<para>For more info, see the Loopback-Root-FS
			HOWTO at <ulink
			url="http://linuxdoc.org/HOWTO/mini/Loopback-Root-FS.html">
			http://linuxdoc.org/HOWTO/mini/Loopback-Root-FS.html
			</ulink></para>
		</sect3>

	</sect2>

	<sect2>
		<title>ROMFS Flash Filesystem</title>

		<para>Search for <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=romfs">
		ROMFS</ulink>.</para>

	</sect2>

	<sect2>
		<title>cramfs</title>

		<para>The 2.4 kernel series has a compressed read-only
		filesystem (cramfs) aimed at embedded systems, which
		can be  back-ported to 2.2 kernels.  If you're cross-
		developing, you need to modify
		<filename>mkcramfs</filename> to swap between little
		and big endian.</para>
		<para>It turns out that cramfs is not supported for a 
		root fs or initrd. Basically, the kernel checks a 
		hardcoded list of supported filesystems and if the 
		MAGIC number doesn't match it bails.</para>


	</sect2>

	<sect2>
		<title>ramfs</title>

		<para>ramfs from the 2.4 kernel is a simple filesystem
		ideal for use in a ramdisk. It can be used in
		combination with a cramfs read-only root filesystem,
		to mount writable filesystems on
		<filename>/tmp</filename> and
		<filename>/var</filename>, which typically need to be
		writable. This combination is ideal for systems which
		don't require persistent storage.</para>

	</sect2>

	<sect2 id="jffs">
		<title>Journaling Flash FileSystem(JFFS)</title>

		<para><ulink
		url="http://www.developer.axis.com/software/jffs/">
		http://www.developer.axis.com/software/jffs/</ulink></para>

		<para>JFFS allows persistent storage, optimised for
		flash memories rather than block devices like hard
		disks. It is aimed at providing a crash/powerdown-safe
		filesystem for disk-less embedded devices and is a
		better option than the cramfs/ramfs combination if
		your application requires persistent storage. You use
		it with the <link linkend="mtd">MTD</link>
		subsystem.</para>
	</sect2>

</sect1>

<sect1 id="floating">
	<title>Floating Point</title>

	<para>Some of the embedded PowerPC processors do not have a
	floating point unit(FPU), and so must perform all floating point
	operations in software. Others do have a hardware FPU unit and
	may perform operations in hardware.</para>

	<sect2>
		<title>Software</title>

		<para>If your application has very intensive floating
		point requirements, you may need to switch to fixed
		point or choose a target processor which does have an
		FPU. </para>

		<para>Floating point can be performed either by instruction
		emulation  in the kernel, or by compiling
		<emphasis>everything</emphasis> with
		<option>-msoft-float</option>. In particular, it's
		important that all the libraries, whether dynamically
		or statically linked are compiled with the same
		options as the binaries that use them. Unless you're
		using a toolkit where this has already been done for
		you, this will generally mean that if you wish to use
		<option>-msoft-float</option> to gain maximum
		performance, you need to (re)compile
		<emphasis>everything</emphasis>, including:

		<itemizedlist>
			<listitem>
			<para>All static and shared libraries</para>
			</listitem>
			<listitem>
			<para>The compiler's internal libraries,
			such as <filename>libgcc.a</filename></para>
			</listitem>
			<listitem>
			<para>All executables</para>
			</listitem>
		</itemizedlist>

		You will almost certainly not get this right first
		time. The primary symptom is that
		<command>printf</command> gives bogus numbers for
		simple floating point values.</para>

		<para>However, if you succeed, you can save space by
		configuring the kernel without floating point
		emulation. </para>

		<para>See <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199911/msg00056.html">
		http://lists.linuxppc.org/listarcs/
		linuxppc-embedded/199911/msg00056.html</ulink></para>

		<para>To add kernel math emulation to the 2.2.13
		kernel, see <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00017.html">
		http://lists.linuxppc.org/listarcs/
		linuxppc-embedded/199912/msg00017.html</ulink></para>

		<para>The "paranoia" test should give no complaints if
		everything is working correctly. See <ulink
		url="http://www.enseeiht.fr/NetLib/paranoia/index.html">
		http://www.enseeiht.fr/NetLib/paranoia/index.html</ulink>
		</para>

	</sect2>

	<sect2>
		<title>Hardware</title>

		<para>If your <acronym>CPU</acronym> has an
		<acronym>FPU</acronym>, you'll want to use
		it. Make sure that everything is consistently compiled
		for hardware floating point, especially if you've
		assembled your toolkit yourself, or are using an 8xx
		toolkit to compile for the 8260.</para>

		<para>Programs compiled for hardware floating point
		can still run on a <acronym>CPU</acronym> without an
		<acronym>FPU</acronym>, provided the kernel is built
		with the floating point instruction emulator. This
		incurs a further performance penalty on
		<acronym>CPU</acronym>s lacking an
		<acronym>FPU</acronym>.</para>

	</sect2>

	<sect2>
		<title>Mixed</title>

		<para>If you are using a single set of shared
		libraries, you cannot mix the two techniques in the
		one system. If you link statically or try
		<emphasis>really</emphasis> hard by creating two sets
		of shared libraries, the two can co-exist since
		programs compiled with <option>-msoft-float</option>
		never generate floating point instructions requiring
		kernel emulation.</para>

		<para>In general, you're better off choosing one or
		the other, and choosing hardware floating point with
		kernel instruction emulation is much easier to get
		working correctly.</para>

	</sect2>

</sect1>

<sect1>
	<title>Realtime Response</title>

	<para>Check out MontaVista's Linux Real-Time characterisation
	projects at <ulink url="http://www.mvista.com/realtime">
	http://www.mvista.com/realtime</ulink></para>

	<sect2>
		<title>Soft</title>

		<para>For many applications a soft realtime user
		space thread is adequate, particularly if you minimize
		kernel scheduling latency with the patches at <ulink
		url="http://www.redhat.com/~mingo/lowlatency-patches/">
		http://www.redhat.com/~mingo/lowlatency-patches/</ulink>
		</para>

		<para>Also, see <ulink url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00006.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/
		199912/msg00006.html</ulink></para>

	</sect2>

	<sect2>
		<title>Hard</title>

		<para>If your application requires a hard real time
		response with guaranteed low latency, you may need to
		encapsulate the realtime aspects in a device
		driver. This is how devices that have realtime
		constraints such as serial ports and disk drives are
		traditionally handled under most non-realtime
		operating systems, including Linux.</para>

		<sect3>
			<title>Interrupt Latency</title>

			<para>The realtime response of a driver will
			still be affected by other kernel code which
			may disable interrupts for unknown periods,
			increasing effective interrupt latency. For
			some tools to help measure interrupt latency,
			see <ulink
			url="http://www.drfruitcake.com/linux/irq_blk.html">
			http://www.drfruitcake.com/linux/irq_blk.html</ulink>
			</para>

		</sect3>

		<sect3>
			<title>RTLinux - Real-Time Linux</title>

			<para><ulink url="http://www.rtlinux.com/">
			http://www.rtlinux.com/</ulink></para>

			<para>If you need better latency guarantees
			than offerred by the kernel, use Real-Time
			Linux to decouple the hard realtime portion
			from the rest of your application. v3.0
			includes support for PowerPC.</para>

			<para>Also, search for <ulink
			url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=RTLinux">
			RTLinux</ulink>.</para>

		</sect3>

		<sect3>
			<title>RTAI - Real Time Application Interface</title>

			<para><ulink
			url="http://www.aero.polimi.it/projects/rtai/">
			http://www.aero.polimi.it/projects/rtai/</ulink>
			</para>

			<para>The Real Time Application Interface is a
			kernel module which uses a hardware
			abstraction layer to add typical features from
			an industrial realtime operating system to
			Linux. It consists basically of an interrupt
			dispatcher and mainly traps the peripherals
			interrupts and if necessary re-routes them to
			Linux. </para>

			<para>RTAI is supported on a number of MPC8xx
			systems by people like <link
			linkend="Denx">Denx</link>.</para>

		</sect3>

	</sect2>

</sect1>

<sect1 id="threads">
	<title>Threads</title>

	<para>If you need multithreading, using POSIX threads will
	give your application portability, even to non-Linux embedded
	systems. For example, they're supported by EL/IX (see <ulink
	url="http://sources.redhat.com/elix/">http://sources.redhat.com/
	elix/</ulink>), <link linkend="eCos">eCos</link>, <link
	linkend="RTEMs">RTEMs</link>, and virtually all desktop
	systems. </para>

	<para>POSIX threads support is supplied with glibc2 as an
	add-on, enabled by configuring with
	<literal>'--enable-add-ons=linuxthreads'</literal>.</para>

	<para>It is also possible to build older (i.e. smaller) libc5
	with LinuxThreads. See <ulink
	url="http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html">
	http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html</ulink>
	</para>

	<para>LinuxThread support has now been integrated into the
	official <command>gdb</command> release (currently 5.0), which
	makes thread debugging much easier. Versions of
	<command>gdb</command> prior to 5.0 did not support threads
	directly, although you can 'attach' to the thread processes
	individually.</para>

	<para>The courageous can also call
	<classname>clone()</classname> directly. </para>

</sect1>

<sect1 id="applications">
	<title>Applications</title>

	<sect2>
		<title>Standard GNU tools</title>

		<para>Standard GNU tools (such as
		<application>bash</application>,
		<application>ls</application>, etc) are available in
		the MontaVista distribution at <ulink
		url="ftp://ftp.mvista.com/pub/CDKit/1.2/latest/PowerPC">
		ftp://ftp.mvista.com/pub/CDKit/1.2/latest/PowerPC</ulink>
		</para>

		<para>Even if you are compiling them yourself, you can
		use the recipe in the %build portion of the SPEC files
		in the <acronym>SRPM</acronym>s to help.</para>

	</sect2>

	<sect2>
		<title>Standalone Shell</title>

		<para>Also known as <firstterm>sash</firstterm>, this
		is a small standalone shell with minimal versions of
		the most useful commands from
		<filename>/bin</filename> built in. See <ulink
		url="http://www.canb.auug.org.au/~dbell/programs/sash-3.4.tar.gz">
		http://www.canb.auug.org.au/~dbell/programs/sash-3.4.tar.gz
		</ulink></para>

		<para>Not to be confused with the
		<option>CONFIG_SASH</option> configuration option in
		many kernels, which starts a shell at bootup with the
		proper process group settings, so that signals like
		interrupt on <keycap>CTRL-C</keycap> work. Note that
		the two are often used together.</para>

	</sect2>

	<sect2>
		<title>BusyBox</title>

		<para><ulink
		url="http://busybox.lineo.com/">http://busybox.lineo.com/
		</ulink></para>

		<para><application>BusyBox</application> combines tiny
		versions of many common UNIX utilities into a single
		small executable. It provides minimalist replacements
		for most of the utilities you usually find in
		<application>fileutils</application>,
		<application>shellutils</application>,
		<application>findutils</application>,
		<application>textutils</application>,
		<application>grep</application>, <application>gzip
		</application>, <application>tar</application>, etc.
		<application>BusyBox</application> provides a fairly
		complete POSIX environment for any small or embedded
		system. The utilities in BusyBox generally have fewer
		options than their full-featured GNU cousins; however,
		the options that are included provide the expected
		functionality and behave very much like their GNU
		counterparts.</para>

	</sect2>

	<sect2>
		<title>Web Servers</title>

		<para>There are stacks to choose from. Here are just a
		few, which seem particularly well-suited to embedded
		Linux work.  Pick the one that has the features you
		need. </para>

		<sect3>
			<title>Boa</title>

			<para><ulink
			url="http://www.boa.org/">http://www.boa.org/</ulink>
			</para>

			<para>Boa is a single-tasking HTTP
			server. That means that unlike traditional web
			servers, it does not fork for each incoming
			connection, nor does it fork many copies of
			itself to handle multiple connections. It
			internally multiplexes all of the ongoing HTTP
			connections, and forks only for CGI programs
			(which must be separate processes), automatic
			directory generation, and automatic file
			gunzipping. Preliminary tests show Boa is
			capable of handling several thousand hits per
			second on a 300 MHz Pentium and dozens of hits
			per second on a lowly 20 MHz 386/SX.</para>

		</sect3>

		<sect3>
			<title>thttpd, mini_httpd, micro_httpd</title>

			<para><ulink url="http://www.acme.com/">
			http://www.acme.com/</ulink></para>

			<para>A collection of very small web servers,
			with varying degrees of functionality.</para>

		</sect3>

	</sect2>

	<sect2>
		<title>Graphical User Interface</title>

		<sect3>
			<title>Microwindows</title>

			<para><ulink
			url="http://microwindows.censoft.com/">
			http://microwindows.censoft.com/</ulink></para>

			<para>Microwindows is an Open Source project
			aimed at bringing the features of modern
			graphical windowing environments to smaller
			devices and platforms. It allows applications
			to be built and tested on the Linux desktop,
			as well as cross-compiled for the target
			device. </para>

		</sect3>

		<sect3>
			<title>PicoGUI</title>

			<para><ulink url="http://pgui.sourceforge.net/">
			http://pgui.sourceforge.net/</ulink></para>

			<para>A small, portable, client/server GUI
			designed to work on many types of hardware
			including handheld computers. Includes layout
			manager and widgets.</para>

		</sect3>

	</sect2>

	<sect2>
		<title>Java Virtual Machine(JVM)</title>

		<para><link linkend="montavista">MontaVista</link>
		have several JVM solutions for <link
		linkend="hardhat">HardHat Linux</link>.</para>

		<para>A list of Java virtual machines, some of which
		are suitable for embedded PowerPC systems, is
		available at <ulink
		url="http://www.geocities.com/marcoschmidt.geo/java.html">
		http://www.geocities.com/marcoschmidt.geo/java.html</ulink>
		</para>

	</sect2>

</sect1>

<sect1>
	<title>Debugging</title>

	<sect2 id="bdm">
		<title>BDM</title>

		<para>BDM is way cool, especially if you are bringing
		up a custom board and don't want to invest in an In
		Circuit Emulator. You should definitely include a BDM
		connector on any custom hardware, and all
		off-the-shelf boards have it. For a broad
		introduction, see <ulink
		url="http://www.macraigor.com/zenofbdm.pdf">
		http://www.macraigor.com/zenofbdm.pdf</ulink></para>

		<para>Be careful to ensure that the CPU watchdog is
		disabled in the configuration file for your BDM
		probes,  otherwise it will continually reset the CPU
		and nothing will work. In particular, the watchdog is
		enabled at reset and must be disabled if you wish to
		single step from reset. Also check that DER is zero'd
		when running with the debugger. Leaving the BDM probe
		connected can interfere with the target if it is not
		configured absolutely correctly, which usually
		involves the BDM probe being completely passive once
		the kernel is running. Symptoms are that the kernel
		crashes with the BDM probe connected, but runs fine
		without it. If you are using BDM and experience
		unexpected kernel crashes, try disconnecting the BDM
		probe. </para>

		<para>If you're using an off-the-shelf board which
		already has a working <link linkend="rom-monitor">rom
		monitor</link>, you generally won't need to use BDM at
		all, as you can get by fine with just the <link
		linkend="serial-console">serial console</link>. Many
		developers, particularly those bringing up a custom
		board from scratch, find BDM invaluable; to others it
		can be more trouble than it's worth. One advantage of
		a BDM interface over a kernel debugger is that you can
		really "freeze" the CPU including all timers,
		interrupts etc.</para>


		<sect3 id="bdmmmu">
			<title>MMU Support</title>

			<para>Some BDM debuggers are capable of
			performing <link linkend="MMU">MMU</link>
			table walks, which is essential for debugging
			in virtual memory environments such as Linux
			because otherwise the BDM port merely deals
			with raw physical addresses. However, many BDM
			systems can't do this, so check with the
			vendor that they support MMU table walks on
			the particular CPU you're interested in before
			committing to one; otherwise it will be almost
			impossible to use once the kernel has turned
			the MMU on. See <ulink
			url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00021.html">
			http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00021.html
			</ulink></para>

			<para>Once the kernel is running you can <link
			linkend="gdb">use <command>gdb</command>
			remotely </link> or even run it natively on
			the target hardware if you have enough RAM. It
			may be worth providing extra RAM on some of
			your development boards to allow for this. </para>

		</sect3>

		<sect3>
			<title>GDB on BDM</title>

			<para>See "Using GDB for Remote Debugging: BDM
			Support" in the CrossGCC FAQ at <ulink
			url="http://www.objsw.com/CrossGCC/FAQ-7.html">
			http://www.objsw.com/CrossGCC/FAQ-7.html</ulink>
			</para>

			<para>BDM debugging under
			<command>gdb</command> is not supported by all
			BDM hardware vendors. See the thread
			<ulink
			url="http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/july/msg00057.html">
			http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/july/msg00057.html
			</ulink>
			</para>

			<para>To support BDM debugging under
			<command>gdb</command> requires the
			appropriate remote-* device in
			<command>gdb</command>, and possibly a kernel
			driver. If you are cross-developing, you must
			configure <command>gdb</command> as follows to
			include the appropriate devices:

			<programlisting id="crossgdb">
    % configure --target=powerpc-linux
			</programlisting>
			</para>

			<para>The following systems currently support
			BDM debugging on <command>gdb</command>: </para>

			<sect4 id="BDM4GDB">
				<title>BDM4GDB</title>

				<para><ulink
				url="http://bdm4gdb.sourceforge.net/">
				http://bdm4gdb.sourceforge.net/</ulink>
				</para>

				<para>An open user-supported project
				to build your own PowerPC BDM
				interface at extremely low
				cost. Supports extensible Flash
				programming and implements
				software-tablewalk so you have <link
				linkend="bdmmmu">MMU
				support</link>. You can use
				<command>gdb</command> to
				debug kernel code (single stepping,
				breakpoints, etc.) and/or inspect
				kernel data.</para>

				<para>If you don't want to build it
				yourself, the adapter is available at
				cost from <link
				linkend="Denx">Denx</link>, subject to
				availability.</para>

			</sect4>

			<sect4 id="MPCBDM">
				<title>MPCBDM</title>

				<para><ulink
				url="http://www.vas-gmbh.de/software/mpcbdm/">
				http://www.vas-gmbh.de/software/mpcbdm/
				</ulink></para>

				<para>The precursor to the <link
				linkend="BDM4GDB">BDM4GDB</link>
				project, courtesy of Frank
				Przybylski. </para>

			</sect4>

			<sect4>
				<title>PPCBDM</title>

				<para><ulink
				url="http://cyclone.parad.ru/ppcbdm/">
				http://cyclone.parad.ru/ppcbdm/</ulink>
				</para>

				<para>The ultra low hardware cost
				precursor to <link linkend="MPCBDM">
				MPCBDM</link> and <link
				linkend="BDM4GDB">BDM4GDB</link>,
				courtesy of Sergey Drazhnikov.</para>
			</sect4>

			<sect4>
				<title>Abatron</title>

				<para><ulink
				url="http://www.abatron.ch/BDI/bdiGDB.html">
				http://www.abatron.ch/BDI/bdiGDB.html</ulink>
				</para>

				<para>Has an ideal BDM/JTAG emulation
				solution for Linux hosting, with Linux
				<link linkend="bdmmmu">MMU
				support</link> specifically in
				mind. It is an Ethernet-based unit
				which has a telnet interface with
				which one can program various popular
				flash parts. This is ideal for Linux
				since one can build a kernel and
				expect script the programming process
				automagically.</para>

				<para>Their external box implements
				the standard <command>gdb</command>
				remote protocol allowing you to host
				debugging on any platform that can
				host <command>gdb</command>.</para>

			</sect4>

			<sect4>
				<title>Avocet Systems (formerly Huntsville Microsystems)</title>

				<para><ulink
				url="http://www.hmi.com/bmd.htm">
				http://www.hmi.com/bmd.htm</ulink></para>

				<para>Patches to add support to
				<command>gdb</command> are available
				in <ulink
				url="ftp://ftp.hmi.com/pub/gdb/">
				ftp://ftp.hmi.com/pub/gdb/</ulink></para>

			</sect4>

			<sect4>
				<title>Macraigor Systems</title>

				<para><ulink
				url="http://www.macraigor.com/">
				http://www.macraigor.com/</ulink></para>

				<para>Currently only support Windows
				platform, but say Linux support for
				the Kestrel device (but not the
				Wiggler, Raven, etc) should be
				available sometime in September 2000.</para>

				<para>OCD Commander is a free assembly
				level debugger for Windows, which may
				work under VMWare. I couldn't get it
				to work with the Raven/Blackbird
				interface on the Embedded Planet CLLF
				under Windows; it wouldn't single-step
				correctly.</para>

				<para>Beware that the 1999 version of
				OCD Commander silently truncates
				S-records longer than 20 bytes during
				download, so you'll need to patch
				<application>objcopy</application> or
				write your own S-record generator to
				work around this.</para>

				<para>They have flash programming
				software available for download, but
				the Web site doesn't mention that it
				isn't actually free: you have to pay
				for the key to use it.</para>

				<para>If you're prepared to do your
				debugging under Windows, you can use
				the Cygwin tools from <ulink
				url="http://sources.redhat.com/cygwin/">
				http://sources.redhat.com/cygwin/</ulink>
				to build a <command>gdb</command>
				cross-debugger which runs under
				Windows and uses the
				<filename>Wigglers.dll</filename> to
				talk to the target. Note that
				<filename>Wigglers.dll</filename> also
				loads other DLLs, so copy all the DLLs
				that come with OCD Commander from
				<ulink 	url="http://www.macraigor.com/">
				http://www.macraigor.com/"</ulink>
				into your gdb directory and use the command:

				<programlisting>
    (gdb) target ocd wiggler
				</programlisting>
				</para>

				<para>You can also do this remotely,
				by using <link
				linkend="rproxy">rproxy, described
				below</link>.</para>

			</sect4>
			<sect4>
				<title>RISCWatch Debugger for PowerPC Processors</title>
				<para><ulink
				url="http://www.chips.ibm.com/products/powerpc/riscwtch/">
				http://www.chips.ibm.com/products/powerpc/riscwtch/</ulink></para>

				<para>RISCWatch is a hardware and software 
				development tool for the PowerPC 600/700 
				Family of microprocessors and the PowerPC
				400Series of Embedded Controllers. The 
				source-level debugger and processor-control
				features provide developers with the tools 
				needed to develop and debug hardware and software.</para> 
			</sect4>

			<sect4>
				<title>WindRiver (formerly EST Corporation)</title>

				<para><ulink
			url="http://www.windriver.com/products/html/embed_dev_tools.html">
			http://www.windriver.com/products/html/embed_dev_tools.html
			</ulink></para>

				<para>They've ported their VisionXD
				UNIX debugger to Linux and it is
				available with their parallel port of
				Ethernet-based probe.  It can program
				flash parts and do source level
				debugging. It costs $6k or $8k
				depending on parport or Ethernet
				connection. The Windows version is
				only $4k. :-/</para>

				<para>Beware that the EST tools don't
				handle the Linux zImage properly. See
				<ulink
				url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200002/msg00073.html">
				http://lists.linuxppc.org/listarcs/
				linuxppc-embedded/200002/msg00073.html</ulink>
				</para>
			</sect4>

		</sect3>

		<sect3>
			<title>Other debuggers</title>

			<para>There are many other sources of BDM
			hardware probes and debuggers, but many
			vendors still lag way behind as far as Linux
			support. Commercial solutions which do not
			support a Linux development host include:</para>

			<sect4>
				<title>Mentor (X-ray)</title>

				<para><ulink
				url="http://www.mentor.com/embedded/xray/index.html">
				http://www.mentor.com/embedded/
				xray/index.html</ulink></para>

			</sect4>

			<sect4>
				<title>Avocet Systems (SourceGate)</title>

				<para><ulink
				url="http://www.hmi.com/bmd.htm">
				http://www.hmi.com/bmd.htm</ulink></para>

			</sect4>

			<sect4>
				<title>Tasking (CrossView Pro)</title>

				<para><ulink
				url="http://www.tasking.com/technology/xvwp.html">
				http://www.tasking.com/technology/xvwp.html
				</ulink></para>

			</sect4>

			<sect4>
				<title>WindRiver (SingleStep)</title>

				<para><ulink
				url="http://www.windriver.com/products/html/singlestep_suite_ds.html">
				http://www.windriver.com/products/html/singlestep_suite_ds.html
				</ulink></para>

			</sect4>

			<sect4>
				<title>Applied Microsystems
				(PowerTap)</title> 

				<para><ulink
				url="http://www.amc.com/products/powertap.html">
				http://www.amc.com/products/
				powertap.html</ulink></para>

			</sect4>

			<sect4>
				<title>Lauterbach</title>

				<para><ulink
				url="http://www.lauterbach.com/">
				http://www.lauterbach.com/</ulink></para>

			</sect4>

		</sect3>

	</sect2>

	<sect2 id="serial-console">
		<title>Serial Console</title>

		<para>Virtually all boards use a serial console on
		<link linkend="SMC">SMC1</link> for boot messages and
		general debugging. Connect it to a serial port on your
		Linux development machine, where you can run minicom
		to interact with the board.</para>

	</sect2>

	<sect2 id="gdb">
		<title>GDB</title>

		<para>Once the kernel is running, you can use
		<command>gdb</command> in several different ways to
		debug user space programs:</para>

		<sect3>
			<title>gdbserver</title>

			<para>You can run gdbserver on your target and
			run <command>gdb</command> back on your
			development machine, even if you're
			cross-developing. This requires far less
			resources than running all of
			<command>gdb</command> on your target. See <ulink
			url="http://qslinux.org/docs/cross/gdb/index.html">
			http://qslinux.org/docs/cross/gdb/index.html</ulink>
			</para>

			<para>If you're cross-developing, remember to
			configure your <command>gdb</command> as
			described <link
			linkend="crossgdb">earlier</link>. </para>

		</sect3>

		<sect3 id="rproxy">
			<title>rproxy</title>

			<para><ulink
			url="http://www.std.com/qqi/labslave/rproxy.html">
			http://www.std.com/qqi/labslave/rproxy.html</ulink>
			</para>

			<para>This in an extended/enhanced gdbserver,
			which can also run on Windows and talk to BDM
			devices not yet supported by Linux.</para>

		</sect3>

		<sect3>
			<title>native</title>

			<para>If you have lots of RAM, you can run
			<command>gdb</command> directly on your
			target. If you are cross-developing, you need
			to configure <command>gdb</command> with: 
			<programlisting>
    % configure --host=powerpc-linux
			</programlisting>
			</para>
		</sect3>

	</sect2>

	<sect2>
		<title>Kernel</title>

		<para>Some kernels include <command>kgdb</command>
		support for using <command>gdb</command> for kernel
		debugging, enabled by configuring with
		<option>CONFIG_KGDB</option>.</para>

	</sect2>

	<sect2>
		<title>Oops Messages</title>

		<para>You get these whenever something truly bad
		happens in the kernel. Learn to know and respect them
		--  they are your friends, not your enemies. For
		general info on how to understand them, see the file
		<filename>Documentation/oops-tracing.txt</filename> in
		the kernel source tree.</para>

		<para>You'll get a long way just by looking up the
		instructions at the address indicated by NIP on the
		first line of the Oops in the output of:
		<programlisting>
objdump --disassemble vmlinux
		</programlisting>

		This will show you the instruction causing the
		fault. Work backwards to find the line of C source
		code associated with it, and add printk's around it to
		find what is going wrong.</para>

		<para>For more help with decoding kernel panic
		messages, see <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00090.html">
		http://lists.linuxppc.org/listarcs/
		linuxppc-embedded/199912/msg00090.html</ulink></para>

	</sect2>

	<sect2>
		<title>printk</title>

		<para><application>printk</application> is an
		indispensible tool. You can use it to add
		checkpointing, print kernel values that you can't get
		to via <filename>/proc</filename>, etc.  It can be
		called anywhere, including interrupt routines,
		provided you're prepared for some interesting
		output.</para>

		<para>Note that during the boot process, the kernel
		"prints" lots of stuff, and it all goes into a buffer,
		to emerge quite late in the boot process when the
		serial console port is initialized with the call to
		<option>console_init</option>. This eventually calls
		<option>register_console</option> which will dump out
		the logged messages. So you can't necessarily assume
		that the kernel didn't get to your checkpoint just
		because the printk message didn't appear on the serial
		port during this part of the boot sequence.</para>

	</sect2>

</sect1>

<sect1>
	<title>Performance</title>

	<sect2>
		<title>CPU core</title>

		<sect3>
			<title>Cache</title>

			<note><para>Ensure you have both the I
			and D caches enabled!</para></note>

			<para>Also, make sure you have serialization
			disabled (Set <envar>ICTRL</envar> to 0x7).</para>

			<para>To get maximum performance, you need to
			enable copyback data cache. This can be
			disabled in order to make the standard
			Linux/PPC libraries work without
			recompiling. If you build your own glibc as
			described under <link
			linkend="library">Runtime Library</link>, you
			can enable copyback. Look for a <option>make
			config</option> option, or
			<command>grep</command> for
			<literal>DC_SFWT</literal> in
			<filename>arch/ppc/kernel/head.S</filename>
			and change the <literal>#if 0</literal> to
			<literal>#if 1</literal>.</para>
		</sect3>

		<sect3>
			<title>BogoMIPS</title>

			<para>The BogoMIPS value on 8xx processors
			should be within 1% or so of the actual CPU
			core frequency, allowing for rounding and
			minor timing calculation errors. This makes it
			a useful sanity check to verify that the
			internal clock multiplier is set correctly
			and that the I-cache is turned on. However,
			note that the calculation of the BogoMIPS
			value is still tied to the external clock
			source and internal prescaler settings, so it
			shouldn't be solely relied on to verify that
			the core frequency really is what you think it
			should be. A simple cross-check is to perform
			a 'sleep 10' at the shell prompt, and time it
			with a watch to check that you're at least in
			the ballpark. It's wise to measure your system
			more accurately than this with a CRO at least
			once.</para>

			<para>Also, beware that the BogoMIPS rating
			should not be used as a general CPU
			performance measure. See <ulink
			url="http://linuxdoc.org/HOWTO/mini/BogoMips.html">
			http://linuxdoc.org/HOWTO/mini/BogoMips.html</ulink>
			</para>
		</sect3>

	</sect2>

	<sect2>
		<title>Profiling</title>

		<para>There are numerous options available for system
		profiling, depending on what you wish to measure, and
		how invasive you are prepared to be.</para>

		<sect3>
			<title>/proc/profile</title>

			<para><filename>/proc/profile</filename> is a
			standard kernel feature which provides simple
			kernel profiling based on Instruction Pointer
			sampling in the periodic timer interrupt
			routine. It's simplistic but effective, and
			low overhead since the interrupt is going to
			happen anyway. The data is processed with
			<application>readprofile</application> which
			looks up the <filename>System.map</filename>
			to show which kernel functions are using the
			most CPU time. It doesn't work for modules yet
			so at present you need to compile them in for
			profiling.</para>

			<para>You need to enable this at boot time by
			passing <parameter>profile=2</parameter> on
			the command line. The number gives the power
			of 2 granularity used for the counters -- 2
			will give you a seperate counter for each
			PowerPC instruction (each 4 bytes). Higher
			numbers consume less memory and give less
			precise results. The data from
			<filename>/proc/profile</filename> will be in
			target byte order, so if you're
			cross-developing you may need to either byte
			swap it, or compile
			<application>readprofile</application> to run
			on your target.</para>

			<para>The PowerPC branch of the Linux kernel
			has been slow to implement the Instruction
			Pointer sampling function necessary to
			generate the
			<filename>/proc/profile</filename> data.  If
			it isn't implemented in your kernel, you'll
			see that
			<application>readprofile</application> always
			shows zero time for every kernel function.</para>

		</sect3>

		<sect3>
			<title>Linux Trace Toolkit</title>

			<para><ulink url="http://www.opersys.com/LTT">
			http://www.opersys.com/LTT</ulink></para>

			<para>The Linux Trace Toolkit works with an
			instrumented Linux kernel by saving
			time-stamped records of important kernel
			events to a binary data file. A data decoder
			converts the binary data to text and
			calculates statistical summaries, such as
			percent processor utilization by each
			process. The toolkit also includes an
			integrated environment that graphically
			displays the results and provides search
			capability.</para>

			<para>A version for embedded PowerPC targets
			is now available from <ulink
			url="ftp://ftp.mvista.com/pub/LTT">
			ftp://ftp.mvista.com/pub/LTT</ulink></para>

		</sect3>

		<sect3>
			<title>gprof</title>

			<para>All the usual Linux user mode profiling
			tools like <application>gprof</application>
			are available.</para>

		</sect3>

		<sect3>
			<title>kernprof</title>

			<para><ulink
			url="http://oss.sgi.com/projects/kernprof">
			http://oss.sgi.com/projects/kernprof</ulink>
			</para>

			<para>This project aims to make full
			<application>gprof</application> profiling
			available for the kernel.  However, it hasn't
			been ported to the PowerPC architecture yet.</para>

		</sect3>

	</sect2>

	<sect2>
		<title>IDMA</title>

		<para>Beware that <link linkend="IDMA">IDMA</link> on
		the 860 is not designed for high performance, and the
		<link linkend="CPU">CPU</link> gets better throughput
		with explicit cache-bursted programmed I/O. Search for
		<ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=IDMA">
		IDMA</ulink> for more discussion.</para>

		<para>Confusion sometimes arises because <link
		linkend="DMA">DMA</link> transfers in most systems are
		faster than <link linkend="CPU">CPU</link> transfers,
		whereas here the reverse is generally
		true. Furthermore, <link linkend="IDMA">IDMA</link>
		transfers eat into <link linkend="CPM">CPM</link>
		processing time, limiting throughput on other
		communications modules at the same time.</para>

	</sect2>

	<sect2>
		<title>Network</title>

		<para>To get good TCP/IP performance, you need a fast
		<link linkend="CPU">CPU</link>. Using the <link
		linkend="FEC">FEC</link>, a 50 MHz 860P will run about
		30 Mbits/sec TCP/IP, and a 100 MHz 860P will run about
		60 Mbits/sec TCP/IP. The bottleneck is the protocol
		and application processing in the PPC core. The
		performance of a TCP/IP connection scales nearly
		linearly with the processor speed.</para>

		<para>If you need to go faster, use the 8260.</para>

	</sect2>

	<sect2>
		<title>Optimization</title>

		<para>Optimizing everything for space using gcc's
		<option>-Os</option> option is likely to provide both
		the smallest code size and best performance, because
		it inhibits loop unrolling optimisation which tends to
		have a negative effect on embedded processors with
		relatively small cache sizes. Furthermore, PowerPC
		processors can speculatively execute branches
		overlapped with other loop instructions, making the
		branch effectively execute in zero cycles so loop
		unrolling is unnecessary in many circumstances.</para>

	</sect2>

</sect1>

<sect1>
	<title>Common Mistakes and Problems</title>

	<para>Many new developers are likely to encounter at least
	half of the following common problems, which are raised often
	on the <link linkend="mail">mailing list</link>.  Keep
	this section in mind to refer to when you spot the symptom.</para>

	<sect2>
		<title>Changing KERNELBASE/KERNELLOAD</title>

		<para>You don't ever want to change
		<envar>KERNELLOAD</envar> or
		<envar>KERNELBASE</envar>, otherwise the virtual
		memory and MMU code will all break. Search for <ulink
		url="http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query=KERNELBASE">
		KERNELBASE</ulink>.</para>

	</sect2>

	<sect2>
		<title>Leaving the Watchdog enabled</title>

		<para>The watchdog is enabled by default, and needs to
		be disabled at reset for anything including <link
		linkend="bdm">BDM</link> to work.</para>

	</sect2>

	<sect2>
		<title>Mixing code compiled for software and hardware
		floating point</title>

		<para>The usual non-obvious cause of this is combining
		executables compiled with
		<option>-fsoft-float</option> and shared libraries
		compiled with <option>-fhard-float</option>, or
		vice-versa. See <link linkend="floating">floating
		point</link>.</para>

	</sect2>

	<sect2>
		<title>Using an unmodified glibc</title>

		<para>In particular, remember to remove (or correct
		the cache line assumptions in)
		<filename>sysdeps/powerpc/memset.S</filename> before
		building <link
		linkend="glibc">glibc-2.1.3</link>.</para>

	</sect2>

	<sect2>
		<title>"Kernel Mode Software FPU Emulation"
		panic</title>

		<para>This has little to do with floating
		point. Nearly all instructions the processor can't
		decode are vectored to this function. It assumes the
		primary reason you are here is to emulate floating
		point instructions. If the function can't decode the
		instruction as a floating point operation, it is
		really something the processor can't execute, so the
		panic message spews forth.</para>

		<para>This can be either a software or hardware
		bug. If it is a software bug, just unravel the stack
		backtrace and debug it.  It could be a trashed stack
		frame, resulting in a bad function return address, or
		some indirect function call that was not properly
		computed.</para>

		<para>It could also happen because of a hardware bug
		while fetching instructions from memory. Verify the
		NIP instruction that it tried to decode is what is
		really supposed to be at that location in memory. This
		is a typical failure when the UPM is not programmed
		correctly. On a custom board in particular, verify all
		memory cycles an a logic analyser. Disable the cache
		and try again, you will probably get a different
		result.</para>

	</sect2>

	<sect2>
		<title>NFS gives "neighbour table overflow"</title>

		<para>This message is the result of some changes to
		the IP stack software in Linux version 2.2.x +. This
		simply means that you are unable to connect to your
		NFS server. It may be related to the driver, but it
		may also be related to other issues, such as NFS
		server not running or incorrectly installed, no
		physical connectivity to NFS server, etc.  Check the
		configuration of your NFS server and IP network before
		diving into the driver.</para>

	</sect2>

	<sect2>
		<title>"Kernel panic: No init found..." on startup</title>

		<para>Either you don't have an
		<application>init</application> program of some type
		(even <filename>/bin/sh</filename>) in your root
		filesystem, or you don't have enough shared libraries
		and the program can't be loaded properly, although you
		often get messages about not able to load some
		<filename>.so</filename>. Usually the problem is
		missing or misplaced shared libraries.</para>

		<para>To start up <filename>/bin/sh</filename>, which
		is a good thing to try initially, you need the entire
		set of glibc shared libraries and
		<filename>libtermcap.so</filename>. If you're using
		the <link linkend="montavista">MontaVista</link> CDK,
		you get these from the <filename>glibc</filename> and
		<filename>termcap</filename> RPMs, and remember you
		also need that funky sym link:
		<filename>/opt/hardhat/devkit/ppc/8xx/powerpc-hardhat-linux
		-> /</filename> in the target filesystem. 
		</para>

		<para>You can find out which shared libraries any
		binary requires using <command>ldd(1)</command>, but
		it only runs on the target and isn't much use if
		you're cross-developing and can't even start a shell
		yet. A shell script which runs on the host and does
		much the same thing is available at <ulink
		url="http://lists.linuxppc.org/listarcs/linuxppc-embedded/200102/msg00011.html">
		http://lists.linuxppc.org/listarcs/linuxppc-embedded/200102/msg00011.html
		</ulink></para>

	</sect2>

</sect1>

<sect1>

	<title>Alternatives</title>

	<para>There are too many commercial embedded operating systems
	to list here, but if Linux isn't to your liking, here are some
	other open source operating systems which share some of the
	same benefits, and have been ported to embedded PowerPC
	processors: </para>

	<sect2 id="eCos">
		<title>eCos - Embedded Configurable Operating System</title>

		<para><ulink url="http://sources.redhat.com/ecos/">
		http://sources.redhat.com/ecos/</ulink></para>

		<para>eCos is an open-source, royalty-free, highly
		configurable, application-specific operating system
		ideal for embedded systems development. It is targeted
		at high-volume applications in consumer electronics,
		telecommunications, automotive, and other deeply
		embedded applications.</para>

	</sect2>

	<sect2 id="RTEMs">
		<title>RTEMs - Real Time Executive for Multiprocessor
		Systems</title>

		<para><ulink
		url="http://www.rtems.com/">http://www.rtems.com/</ulink>
		</para>

		<para>RTEMS is a real-time executive which provides a
		high performance environment for embedded applications
		including a POSIX 1003.1b API, TCP/IP stack,
		multitasking, debugging and filesystem support.</para>

	</sect2>

</sect1>

<sect1>
	<title>Glossary</title>

<glosslist>
	<glossentry>
		<glossterm id="ABI">ABI Application Binary
		Interface</glossterm>
		<glossdef>
		<para>The convention for register usage and C linkage
		commonly used on desktop PowerPC machines. Similar,
		but not identical to the <link
		linkend="EABI">EABI</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm>BDM - Background Debug Mode</glossterm>
		<glossdef>
		<para>An on-chip <link linkend="bdm">debugging</link>
		interface, largely eliminating the need for expensive
		In-Circuit Emulators.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="CPM">CPM - Communications Processor
		Module</glossterm>
		<glossdef>
		<para>The magic communications co-processor in
		Motorola PowerQUICC devices. It contains <link
		linkend="SCC">SCCs</link> and <link
		linkend="SMC">SMCs</link>, and performs <link
		linkend="SDMA">SDMA</link> and <link linkend="IDMA">
		IDMA</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="CPU">CPU - Central Processor
		Unit</glossterm> 
		<glossdef>
		<para>Depending on the context, this may refer to the
		PowerPC core itself, or the physical processor device
		(including <link linkend="CPM">CPM</link>, <link
		linkend="SIU">SIU</link>, packaging etc) as a single
		unit. </para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="DMA">DMA - Direct Memory
		Access</glossterm>
		<glossdef>
		<para>A form a data transfer directly between memory
		and a peripheral or between memory and memory, without
		normal program intervention.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="EABI">EABI - Embedded Application
		Binary Interface</glossterm>
		<glossdef>
		<para>The convention for register usage and C linkage
		commonly used on embedded PowerPC machines, derived
		from the <link linkend="ABI">ABI</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="FEC">FEC - Fast Ethernet
		Controller</glossterm> 
		<glossdef>
		<para>The 100 Mbps (100Base) Ethernet controller,
		present on 'T' devices such as the 860T and
		855T.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="GPL">GPL/LGPL - GNU General Public
		License/Lesser General Public License</glossterm>
		<glossdef>
		<para><ulink url="http://www.gnu.org/copyleft/gpl.html">
		http://www.gnu.org/copyleft/gpl.html</ulink></para>

		<para>The licenses under which the Linux kernel and
		much of the utility and library code necessary to
		build a complete system may be copied, distributed and
		modified. Each portion of the software is copyright by
		its respected copyright holder, and you must comply
		with the terms of the license in order to legally copy
		(and hence use) it.  One significant requirement is
		that you freely redistribute any modifications you
		make; if you can't cope with this, embedded Linux
		isn't for you.</para>
		</glossdef>
	</glossentry>
	
	<glossentry>
		<glossterm id="IDMA">IDMA - Independent
		DMA</glossterm>
		<glossdef>
		<para>A general purpose <link linkend="DMA">DMA</link>
		engine with relatively limited throughput provided by
		the microcoded <link linkend="CPM">CPM</link>, for use
		with external peripherals or memory-to-memory
		transfers. </para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="MII">MII - Media Independent
		Interface</glossterm> 
		<glossdef>
		<para>The IEEE Ethernet standard control interface
		used to communicate between the on-chip Ethernet
		controller and the external <link
		linkend="PHY">PHY</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="MMU">MMU - Memory Management
		Unit</glossterm> 
		<glossdef>
		<para><link linkend="CPU">CPU</link> component which
		maps kernel- and user-space virtual addresses to
		physical addresses, and is an integral part of Linux
		kernel operation.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="PHY">PHY - Physical
		Interface</glossterm>
		<glossdef>
		<para>The IEEE Ethernet standard interface between the
		external physical layer transceiver and the on-chip
		ethernet controller in a PowerQUICC device. Often used
		to refer to the external transceiver itself, the PHY
		is controlled more or less transparently to software
		via the <link linkend="MII">MII</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="SCC">SCC - Serial Communications
		Controller</glossterm>
		<glossdef>
		<para>The high performance module(s) within the <link
		linkend="CPM">CPM</link> which implement the lowest
		layer of various serial protocols, such as
		Asynchronous serial (<link
		linkend="UART">UART</link>), 10 Mbps Ethernet, HDLC
		etc.</para> 
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="SDMA">SDMA - Serial DMA</glossterm>
		<glossdef>
		<para><link linkend="DMA">DMA</link> used to transfer
		data to and from the <link
		linkend="SCC">SCCs.</link></para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="SIU">SIU - System Interface
		Unit</glossterm>
		<glossdef>
		<para>Provides much of the external interfacing
		logic. It's  the other major module on Motorola
		PowerQUICC devices alongside the CPU core and <link
		linkend="CPM">CPM</link>.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="SPI">SPI - Serial Peripheral
		Interface</glossterm>
		<glossdef>
		<para>A relatively simple synchronous serial interface
		for connecting low speed external devices using
		minimal wires.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="SMC">SMC - Serial Management
		Controller</glossterm> 
		<glossdef>
		<para>A lower performance version of the <link
		linkend="SCC">SCCs</link> with more limited
		functionality, particularly useful for serial debug
		ports and low throughput serial protocols.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="UART">UART - Universal Asynchronous
		Receiver Transmitter</glossterm>
		<glossdef>
		<para>Generically, this refers to any device capable
		of implementing a variety of asynchronous serial
		protocols, such as RS-232, HDLC and SDLC. In this
		context, it refers to the operating mode of the <link
		linkend="SCC">SCCs</link> which provides this
		functionality.</para>
		</glossdef>
	</glossentry>

	<glossentry>
		<glossterm id="UPM">UPM - User Programmable
		Machine</glossterm>
		<glossdef>
		<para>A highly flexible bus interfacing machine unit
		allowing external peripherals with an extremely wide
		variety of interfacing requirements to be connected
		directly to the CPU.</para>
		</glossdef>
	</glossentry>
</glosslist>
</sect1>
<appendix id="gfdl">
<title>GNU Free Documentation License</title>
<!-- - GNU Project - Free Software Foundation (FSF) -->
<!-- LINK REV="made" HREF="mailto:webmasters@gnu.org" -->


  <!-- sect1>
    <title>GNU Free Documentation License</title -->

    <para>Version 1.1, March 2000</para>

    <blockquote>
      <para>Copyright (C) 2000  Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.</para>
    </blockquote>

  <sect1 label="0">
    <title>PREAMBLE</title>

    <para>The purpose of this License is to make a manual, textbook,
    or other written document "free" in the sense of freedom: to
    assure everyone the effective freedom to copy and redistribute it,
    with or without modifying it, either commercially or
    noncommercially.  Secondarily, this License preserves for the
    author and publisher a way to get credit for their work, while not
    being considered responsible for modifications made by
    others.</para>

    <para>This License is a kind of "copyleft", which means that
    derivative works of the document must themselves be free in the
    same sense.  It complements the GNU General Public License, which
    is a copyleft license designed for free software.</para>

    <para>We have designed this License in order to use it for manuals
    for free software, because free software needs free documentation:
    a free program should come with manuals providing the same
    freedoms that the software does.  But this License is not limited
    to software manuals; it can be used for any textual work,
    regardless of subject matter or whether it is published as a
    printed book.  We recommend this License principally for works
    whose purpose is instruction or reference.</para>
  </sect1>

  <sect1 label="1">
    <title>APPLICABILITY AND DEFINITIONS</title>

    <para>This License applies to any manual or other work that
    contains a notice placed by the copyright holder saying it can be
    distributed under the terms of this License.  The "Document",
    below, refers to any such manual or work.  Any member of the
    public is a licensee, and is addressed as "you".</para>

    <para>A "Modified Version" of the Document means any work
    containing the Document or a portion of it, either copied
    verbatim, or with modifications and/or translated into another
    language.</para>

    <para>A "Secondary Section" is a named appendix or a front-matter
    section of the Document that deals exclusively with the
    relationship of the publishers or authors of the Document to the
    Document's overall subject (or to related matters) and contains
    nothing that could fall directly within that overall subject.
    (For example, if the Document is in part a textbook of
    mathematics, a Secondary Section may not explain any mathematics.)
    The relationship could be a matter of historical connection with
    the subject or with related matters, or of legal, commercial,
    philosophical, ethical or political position regarding
    them.</para>

    <para>The "Invariant Sections" are certain Secondary Sections
    whose titles are designated, as being those of Invariant Sections,
    in the notice that says that the Document is released under this
    License.</para>

    <para>The "Cover Texts" are certain short passages of text that
    are listed, as Front-Cover Texts or Back-Cover Texts, in the
    notice that says that the Document is released under this
    License.</para>

    <para>A "Transparent" copy of the Document means a
    machine-readable copy, represented in a format whose specification
    is available to the general public, whose contents can be viewed
    and edited directly and straightforwardly with generic text
    editors or (for images composed of pixels) generic paint programs
    or (for drawings) some widely available drawing editor, and that
    is suitable for input to text formatters or for automatic
    translation to a variety of formats suitable for input to text
    formatters.  A copy made in an otherwise Transparent file format
    whose markup has been designed to thwart or discourage subsequent
    modification by readers is not Transparent.  A copy that is not
    "Transparent" is called "Opaque".</para>

    <para>Examples of suitable formats for Transparent copies include
    plain ASCII without markup, Texinfo input format, LaTeX input
    format, SGML or XML using a publicly available DTD, and
    standard-conforming simple HTML designed for human modification.
    Opaque formats include PostScript, PDF, proprietary formats that
    can be read and edited only by proprietary word processors, SGML
    or XML for which the DTD and/or processing tools are not generally
    available, and the machine-generated HTML produced by some word
    processors for output purposes only.</para>

    <para>The "Title Page" means, for a printed book, the title page
    itself, plus such following pages as are needed to hold, legibly,
    the material this License requires to appear in the title page.
    For works in formats which do not have any title page as such,
    "Title Page" means the text near the most prominent appearance of
    the work's title, preceding the beginning of the body of the
    text.</para>
  </sect1>

  <sect1 label="2">
    <title>VERBATIM COPYING</title>

    <para>You may copy and distribute the Document in any medium,
    either commercially or noncommercially, provided that this
    License, the copyright notices, and the license notice saying this
    License applies to the Document are reproduced in all copies, and
    that you add no other conditions whatsoever to those of this
    License.  You may not use technical measures to obstruct or
    control the reading or further copying of the copies you make or
    distribute.  However, you may accept compensation in exchange for
    copies.  If you distribute a large enough number of copies you
    must also follow the conditions in section 3.</para>

    <para>You may also lend copies, under the same conditions stated
    above, and you may publicly display copies.</para>
  </sect1>

  <sect1 label="3">
    <title>COPYING IN QUANTITY</title>

    <para>If you publish printed copies of the Document numbering more
    than 100, and the Document's license notice requires Cover Texts,
    you must enclose the copies in covers that carry, clearly and
    legibly, all these Cover Texts: Front-Cover Texts on the front
    cover, and Back-Cover Texts on the back cover.  Both covers must
    also clearly and legibly identify you as the publisher of these
    copies.  The front cover must present the full title with all
    words of the title equally prominent and visible.  You may add
    other material on the covers in addition.  Copying with changes
    limited to the covers, as long as they preserve the title of the
    Document and satisfy these conditions, can be treated as verbatim
    copying in other respects.</para>

    <para>If the required texts for either cover are too voluminous to
    fit legibly, you should put the first ones listed (as many as fit
    reasonably) on the actual cover, and continue the rest onto
    adjacent pages.</para>

    <para>If you publish or distribute Opaque copies of the Document
    numbering more than 100, you must either include a
    machine-readable Transparent copy along with each Opaque copy, or
    state in or with each Opaque copy a publicly-accessible
    computer-network location containing a complete Transparent copy
    of the Document, free of added material, which the general
    network-using public has access to download anonymously at no
    charge using public-standard network protocols.  If you use the
    latter option, you must take reasonably prudent steps, when you
    begin distribution of Opaque copies in quantity, to ensure that
    this Transparent copy will remain thus accessible at the stated
    location until at least one year after the last time you
    distribute an Opaque copy (directly or through your agents or
    retailers) of that edition to the public.</para>

    <para>It is requested, but not required, that you contact the
    authors of the Document well before redistributing any large
    number of copies, to give them a chance to provide you with an
    updated version of the Document.</para>
  </sect1>

  <sect1 label="4">
    <title>MODIFICATIONS</title>

    <para>You may copy and distribute a Modified Version of the
    Document under the conditions of sections 2 and 3 above, provided
    that you release the Modified Version under precisely this
    License, with the Modified Version filling the role of the
    Document, thus licensing distribution and modification of the
    Modified Version to whoever possesses a copy of it.  In addition,
    you must do these things in the Modified Version:</para>

    <orderedlist numeration="upperalpha">
      <listitem><para>Use in the Title Page
      (and on the covers, if any) a title distinct from that of the
      Document, and from those of previous versions (which should, if
      there were any, be listed in the History section of the
      Document).  You may use the same title as a previous version if
      the original publisher of that version gives permission.</para>
      </listitem>

      <listitem><para>List on the Title Page,
      as authors, one or more persons or entities responsible for
      authorship of the modifications in the Modified Version,
      together with at least five of the principal authors of the
      Document (all of its principal authors, if it has less than
      five).</para>
      </listitem>

      <listitem><para>State on the Title page
      the name of the publisher of the Modified Version, as the
      publisher.</para>
      </listitem>

      <listitem><para>Preserve all the
      copyright notices of the Document.</para>
      </listitem>

      <listitem><para>Add an appropriate
      copyright notice for your modifications adjacent to the other
      copyright notices.</para>
      </listitem>

      <listitem><para>Include, immediately
      after the copyright notices, a license notice giving the public
      permission to use the Modified Version under the terms of this
      License, in the form shown in the Addendum below.</para>
      </listitem>

      <listitem><para>Preserve in that license
      notice the full lists of Invariant Sections and required Cover
      Texts given in the Document's license notice.</para>
      </listitem>

      <listitem><para>Include an unaltered
      copy of this License.</para>
      </listitem>

      <listitem><para>Preserve the section
      entitled "History", and its title, and add to it an item stating
      at least the title, year, new authors, and publisher of the
      Modified Version as given on the Title Page.  If there is no
      section entitled "History" in the Document, create one stating
      the title, year, authors, and publisher of the Document as given
      on its Title Page, then add an item describing the Modified
      Version as stated in the previous sentence.</para>
      </listitem>

      <listitem><para>Preserve the network
      location, if any, given in the Document for public access to a
      Transparent copy of the Document, and likewise the network
      locations given in the Document for previous versions it was
      based on.  These may be placed in the "History" section.  You
      may omit a network location for a work that was published at
      least four years before the Document itself, or if the original
      publisher of the version it refers to gives permission.</para>
      </listitem>

      <listitem><para>In any section entitled
      "Acknowledgements" or "Dedications", preserve the section's
      title, and preserve in the section all the substance and tone of
      each of the contributor acknowledgements and/or dedications
      given therein.</para>
      </listitem>

      <listitem><para>Preserve all the
      Invariant Sections of the Document, unaltered in their text and
      in their titles.  Section numbers or the equivalent are not
      considered part of the section titles.</para>
      </listitem>

      <listitem><para>Delete any section
      entitled "Endorsements".  Such a section may not be included in
      the Modified Version.</para>
      </listitem>

      <listitem><para>Do not retitle any
      existing section as "Endorsements" or to conflict in title with
      any Invariant Section.</para>
      </listitem>
    </orderedlist>
    
    <para>If the Modified Version includes new front-matter sections
    or appendices that qualify as Secondary Sections and contain no
    material copied from the Document, you may at your option
    designate some or all of these sections as invariant.  To do this,
    add their titles to the list of Invariant Sections in the Modified
    Version's license notice.  These titles must be distinct from any
    other section titles.</para>

    <para>You may add a section entitled "Endorsements", provided it
    contains nothing but endorsements of your Modified Version by
    various parties--for example, statements of peer review or that
    the text has been approved by an organization as the authoritative
    definition of a standard.</para>

    <para>You may add a passage of up to five words as a Front-Cover
    Text, and a passage of up to 25 words as a Back-Cover Text, to the
    end of the list of Cover Texts in the Modified Version.  Only one
    passage of Front-Cover Text and one of Back-Cover Text may be
    added by (or through arrangements made by) any one entity.  If the
    Document already includes a cover text for the same cover,
    previously added by you or by arrangement made by the same entity
    you are acting on behalf of, you may not add another; but you may
    replace the old one, on explicit permission from the previous
    publisher that added the old one.</para>

    <para>The author(s) and publisher(s) of the Document do not by
    this License give permission to use their names for publicity for
    or to assert or imply endorsement of any Modified Version.</para>
  </sect1>

  <sect1 label="5">
    <title>COMBINING DOCUMENTS</title>

    <para>You may combine the Document with other documents released
    under this License, under the terms defined in section 4 above for
    modified versions, provided that you include in the combination
    all of the Invariant Sections of all of the original documents,
    unmodified, and list them all as Invariant Sections of your
    combined work in its license notice.</para>

    <para>The combined work need only contain one copy of this
    License, and multiple identical Invariant Sections may be replaced
    with a single copy.  If there are multiple Invariant Sections with
    the same name but different contents, make the title of each such
    section unique by adding at the end of it, in parentheses, the
    name of the original author or publisher of that section if known,
    or else a unique number.  Make the same adjustment to the section
    titles in the list of Invariant Sections in the license notice of
    the combined work.</para>

    <para>In the combination, you must combine any sections entitled
    "History" in the various original documents, forming one section
    entitled "History"; likewise combine any sections entitled
    "Acknowledgements", and any sections entitled "Dedications".  You
    must delete all sections entitled "Endorsements."</para>
  </sect1>

  <sect1 label="6">
    <title>COLLECTIONS OF DOCUMENTS</title>

    <para>You may make a collection consisting of the Document and
    other documents released under this License, and replace the
    individual copies of this License in the various documents with a
    single copy that is included in the collection, provided that you
    follow the rules of this License for verbatim copying of each of
    the documents in all other respects.</para>

    <para>You may extract a single document from such a collection,
    and distribute it individually under this License, provided you
    insert a copy of this License into the extracted document, and
    follow this License in all other respects regarding verbatim
    copying of that document.</para>
  </sect1>

  <sect1 label="7">
    <title>AGGREGATION WITH INDEPENDENT WORKS</title>
    
    <para>A compilation of the Document or its derivatives with other
    separate and independent documents or works, in or on a volume of
    a storage or distribution medium, does not as a whole count as a
    Modified Version of the Document, provided no compilation
    copyright is claimed for the compilation.  Such a compilation is
    called an "aggregate", and this License does not apply to the
    other self-contained works thus compiled with the Document, on
    account of their being thus compiled, if they are not themselves
    derivative works of the Document.</para>

    <para>If the Cover Text requirement of section 3 is applicable to
    these copies of the Document, then if the Document is less than
    one quarter of the entire aggregate, the Document's Cover Texts
    may be placed on covers that surround only the Document within the
    aggregate.  Otherwise they must appear on covers around the whole
    aggregate.</para>
  </sect1>

  <sect1 label="8">
    <title>TRANSLATION</title>

    <para>Translation is considered a kind of modification, so you may
    distribute translations of the Document under the terms of section
    4.  Replacing Invariant Sections with translations requires
    special permission from their copyright holders, but you may
    include translations of some or all Invariant Sections in addition
    to the original versions of these Invariant Sections.  You may
    include a translation of this License provided that you also
    include the original English version of this License.  In case of
    a disagreement between the translation and the original English
    version of this License, the original English version will
    prevail.</para>
  </sect1>

  <sect1 label="9">
    <title>TERMINATION</title>
    
    <para>You may not copy, modify, sublicense, or distribute the
    Document except as expressly provided for under this License.  Any
    other attempt to copy, modify, sublicense or distribute the
    Document is void, and will automatically terminate your rights
    under this License.  However, parties who have received copies, or
    rights, from you under this License will not have their licenses
    terminated so long as such parties remain in full
    compliance.</para>
  </sect1>

  <sect1 label="10">
    <title>FUTURE REVISIONS OF THIS LICENSE</title>

    <para>The Free Software Foundation may publish new, revised
    versions of the GNU Free Documentation License from time to time.
    Such new versions will be similar in spirit to the present
    version, but may differ in detail to address new problems or
    concerns.  See <ulink
    url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.</para>

    <para>Each version of the License is given a distinguishing
    version number.  If the Document specifies that a particular
    numbered version of this License "or any later version" applies to
    it, you have the option of following the terms and conditions
    either of that specified version or of any later version that has
    been published (not as a draft) by the Free Software Foundation.
    If the Document does not specify a version number of this License,
    you may choose any version ever published (not as a draft) by the
    Free Software Foundation.</para>
  </sect1>

  <sect1 label="">
    <title>How to use this License for your documents</title>

    <para>To use this License in a document you have written, include
    a copy of the License in the document and put the following
    copyright and license notices just after the title page:</para>

<blockquote><para>
      Copyright (c)  YEAR  YOUR NAME.
      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.1
      or any later version published by the Free Software Foundation;
      with the Invariant Sections being LIST THEIR TITLES, with the
      Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
      A copy of the license is included in the section entitled "GNU
      Free Documentation License".
</para></blockquote>

    <para>If you have no Invariant Sections, write "with no Invariant
    Sections" instead of saying which ones are invariant.  If you have
    no Front-Cover Texts, write "no Front-Cover Texts" instead of
    "Front-Cover Texts being LIST"; likewise for Back-Cover
    Texts.</para>

    <para>If your document contains nontrivial examples of program
    code, we recommend releasing these examples in parallel under your
    choice of free software license, such as the GNU General Public
    License, to permit their use in free software.</para>
  </sect1>

</appendix>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-parent-document: ("referenz.sgml" "appendix")
sgml-exposed-tags:nil
sgml-local-ecat-files:nil
sgml-local-catalogs: CATALOG
sgml-validate-command: "nsgmls -s referenz.sgml"
ispell-skip-sgml: t
End:
-->


</article>
