view www/new_platform.html @ 328:6a0788146ccb

Because sysfs doesn't have a stable API, the old mdev doesn't work with 2.6.25.
author Rob Landley <rob@landley.net>
date Mon, 12 May 2008 00:55:23 -0500
parents 185081cc4ea9
children
line wrap: on
line source

<!--#include file="header.html" -->

<h2>Setting up a new platform</h2>

<p>The differences between platforms are confined to a single file, which is
the platform configuration file in the <b>sources/configs</b> directory.  The
same scripts build the same packages for each platform, differing only in
which configuration file they read.</p>

<p>Each configuration file sets some environment variables, defines one
shell function, and writes two data files.  The name of the configuration file
is also significant.</p>

<p>Configuration files are read and processed by the script
<b>include.sh</b>.</p>

<h2>Naming your configuration file.</h2>

<p>The name of the platform configuration file is used to form a "tuple" for
gcc and binutils by appending "-unknown-linux" to the filename.  So the first
thing to do is find out what platform name gcc and binutils want for your
target platform, and name your config file appropriately.</p>

<p>(Note: if your platform really can't use an "${ARCH}-unknown-linux" style
tuple, and instead needs a tuple like "bfin-elf", you can set the variable
CROSS_TARGET in the config file to override the default value and feed
some other --target to gcc and binutils.  You really shouldn't have to do
this unless gcc doesn't yet fully support Linux on your platform.  Try the
default first, and fix it if necessary.)</p>

<p>The name of the configuration file is also used in the name of the various
directories generated during the build (temp-$NAME, cross-compiler-$NAME,
and mini-native-$NAME, all in the build/ directory), and as the prefix of the
cross compiler binaries ($NAME-gcc and friends).</p>

<h2>Setting environment variables.</h2>
<p>The following environment variables are usually set in a configuration
file:</p>
<ul>
<li><b>KARCH</b> - architecture value for the Linux kernel (ARCH=$KARCH).  The
Linux kernel uses different names for architectures than gcc or binutils
do.  To see all your options, list the "arch" directory of the linux kernel
source.</li>
<li><b>KERNEL_PATH</b> - Path in the linux kernel source tree where the bootable
kernel image is generated.  This is the file saved out of the kernel build, to
be fed to qemu's -kernel option.  Usually "arch/${KARCH}/boot/zImage", but
sometimes bzImage or image in that directory, sometimes vmlinux in the top
level directory...</li>
<li><b>GCC_FLAGS</b> - Any extra flags needed by gcc.  Usually blank, but
sometimes used to specify a floating point coprocessor or ABI.</li>
<li><b>BINUTILS_FLAGS</b> - Any extra flags needed by binutils.  Usually
blank.</li>
<li><b>QEMU_TEST</b> - At the end of the cross compiler build, a quick sanity
test builds static and dynamic "Hello world!" executables with the new cross
compiler.  Optionally, if QEMU_TEST isn't blank and a file qemu-$QEMU_TEST
exists in the $PATH, the cross compiler build script will then run qemu's
application emulation against the static version of "hello world" as an
additional sanity test, to make sure it runs on the target processor and
outputs "Hello world!".  Leave it blank to skip this test.</li>
</ul>

<h2>emulator_command</h2>

<p>The shell function <b>emulator_command()</b> is used to generate
the run-$ARCH.sh shell script in the build directory.  The function should
output an emulator command line to stdout (generally using "echo").  The
function receives three arguments: $1 is the name of the ext2 image containing
the root filesystem, $2 is the name of the kernel image, $3 is a set of
platform-independent kernel command line arguments (currently "rw
init=/tools/bin/sh panic=1 PATH=/tools/bin") to which emulator_command should
append at least root= and console= arguments.  This function is called from
include.sh.</p>

<a name="miniconfig"><h2>miniconfig-linux</h2>
<p>The Linux kernel needs a configuration file to build.  Firmware Linux
uses the "miniconfig" file format, which contains only the configuration
symbols a user would have to switch on in menuconfig if they started from
allnoconfig.</p>

<p>This file is written as a "here" document, ala:</p>
<blockquote>
<pre>
cat > "${WORK}"/miniconfig-linux << 'EOF'
[insert file contents here]
EOF
</pre>
</blockquote>

<p>To generate a miniconfig, first configure your kernel with menuconfig,
then copy the resulting .config file to a temporary filename (such as
"tempfile").  Then run the miniconfig.sh script in the sources/toys directory
with the temporary file name as your argument and with the environment variable
ARCH set to the $KARCH value in your new config file (and exported if
necessary).  This should produce a new file, "mini.config", which is your
.config file converted to miniconfig format.</p>

<p>For example, to produce a miniconfig for a given platform:</p>
<blockquote>
<pre>
make ARCH=$KARCH menuconfig
mv .config tempfile
ARCH=$KARCH miniconfig.sh tempfile
ls -l mini.config
</pre>
</blockquote>

<p>To expand a mini.config back into a full .config file (to build a kernel
by hand, or for further editing with menuconfig), you can go:</p>

<blockquote>
<pre>
make ARCH=$KARCH allnoconfig KCONFIG_ALLCONFIG=mini.config
</pre>
</blockquote>

<p>Remember to supply an actual value for $KARCH.</p>

<h2>miniconfig-uClibc</h2>

<p>Just like the Linux kernel, uClibc needs a .config file to build, and
so the Firmware Linux configuration file supplies a miniconfig.  Note that
uClibc doesn't require an ARCH= value, because all its architecture information
is stored in the config file.  Otherwise the procedure for creating and using
it is the same as for the Linux kernel, just with a different filename and
contents.</p>

<p>Note that Firmware Linux patches uClibc to work with miniconfig files,
the base uClibc 0.9.29 release doesn't support miniconfig files yet.</p>

<!--#include file="footer.html" -->