Commit f55d8dff authored by Peter Korsgaard's avatar Peter Korsgaard
Browse files

docs: remove outdated files



Misleading/outdated docs is worse than no documentation.

Signed-off-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
parent 87a5a194
Loading
Loading
Loading
Loading

TODO

deleted100644 → 0
+0 −17
Original line number Diff line number Diff line
Buildroot2 TODOs

- fix packages/Makefile.autotools.in to use a package-imposed patchdir
  (Ivan Kuten)
- convert all packages that use autoconf to use the infrastructure of
  packages/Makefile.autotools.in
- fix setting of flags for packages

- coreutils: use make install-strip to install the packages. For now,
  it fails beause even if we pass STRIP="/path/to/$(ARCH)-strip", the
  coreutils build system uses the host strip to strip target
  binaries. The ./configure execution done by Buildroot properly
  detects the cross-strip, but when running make, build-aux/missing
  gets run, complains about aclocal-1.10c and atuomake-1.10c not being
  present, and rerun the configuration... with the wrong environment
  variables (STRIP= is missing). An autoreconf on this package is
  probably necessary.
+1 −3
Original line number Diff line number Diff line
@@ -11,8 +11,6 @@ To build and use the buildroot stuff, do the following:

You do not need to be root to build or run buildroot.  Have fun!

 -Erik

Offline build:
==============

docs/README.diskimage

deleted100644 → 0
+0 −37
Original line number Diff line number Diff line
# Sample for i386 to create a 6MB disk-image

# create an image file
dd if=/dev/zero bs=512 count=$((6*1024*1024/512)) of=img
# create a partition (optional)
echo -e "n\np\n1\n\nw\n" | \
  ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 ./img
# as root, associate the image with a look-device:
# The offset of 512 comes from the the layout of the image. See
# ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 -l ./img for the start
# block and multiply this with the block size (==512).
~/src/busybox/busybox losetup -o 512 /dev/loop/0 /path/to/the/img
# create some filesystem on it, for example ext2
mkfs.ext2 -m0 -Lslash /dev/loop/0
# mount it and copy your stuff to it
~/src/busybox/busybox mount -oloop,rw /dev/loop/0 /media/l0
~/src/busybox/busybox mkdir -p /media/l0/boot/grub
~/src/busybox/busybox cp -a project_build_i386/root/boot/grub/stage? /media/l0/boot/grub/
~/src/busybox/busybox cp -a project_build_i386/root/boot/bzImage /media/l0/boot/
~/src/busybox/busybox cat > /media/l0/boot/grub/menu.lst <<EOF
title=GNU/Linux
root (hd0,0)
kernel /boot/bzImage
EOF
# finally unmount the dist and disassociate the loopdev
~/src/busybox/busybox umount /media/l0
~/src/busybox/busybox losetup -d /dev/loop/0
# now install grub from the chroot
~/src/busybox/busybox losetup /dev/loop/0 /path/to/the/img
project_build_i386/root/usr/sbin/grub --device-map=/dev/null
device (hd0) img
geometry (hd0) 16065 255 63
root (hd0,0)
setup (hd0)
quit
# finally boot the thing
/opt/qemu-trunk_ggi-2.2.2/bin/qemu -snapshot -hda img -boot c

docs/TESTING.html

deleted100644 → 0
+0 −67
Original line number Diff line number Diff line
<!--#include file="header.html" -->

<h2>Testing Buildroot for an Architecture</h2>

<p>
<h4>scripts/mkpkg script</h4>
If you want to test the build of a single package you can use the mkpkg script.
</p>
<p>
<li>$ scripts/mkpkg PACKAGE</li> 
</p>
<p>
Will make the board, and save the result in a log file.
The log file resides in
<li>$ log/OK/PACKAGE.log.OK</li> 
</p>
<p>
if the build succeeds and in
<li>$ log/OK/PACKAGE.log.FAIL</li>
</p>
<p>
if it cannot complete.
</p>

<p>
By creating an alias
<li>alias mk=scripts/mkpkg</li>
</p>
<p>
it is enough to type
<li>$ mk PACKAGE</li> 
</p>
<p>
mkpkg will only print out the <h4>{PACKAGE}......OK</h4> or <h4>{PACKAGE}......FAIL</h4>
depending on success or failure making it easy to get an overview
of the status of this specific architecture.
</p>
<p>
It is recommended to build a simple board before running the test
to get some basic things done.
</p>
<p>
<h4>scripts/buildall.sh script</h4>
</p>
<p>
By running this script you will run scripts/mkpkg on
a lot of the packages available in Buildroot.
</p>
<p>
You need to run the script while in the TOP directory.
I.E: Where you typically run make.
</p>
<p>
There are a few lacking, for no very good reason,
but these can be easily added.
</p>
<p>
Note that some packages will not build properly
if you do not enable them using makeconfig.
</p>
<p>
Examples are:
<li>freetype</li>
<li>socat</li>
</p>

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

docs/U-boot.html

deleted100644 → 0
+0 −254
Original line number Diff line number Diff line
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Buildroot - U-boot extensions in 2009.01-rc1</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
	<link rel="stylesheet" type="text/css" href="stylesheet.css" />
</head>

<body>
	<div class="main">
	<div class="titre">
	<a name="top" id="top"></a>
	<h1>U-boot extensions in 2009.01-rc1</h1>
	</div>

	<p><a href="http://buildroot.net/">U-Boot</a>
	usage and documentation by Ulf Samuelsson.
	</p>

	<ul>
		<li><a href="#about">About U-Boot</a></li>
		<li><a href="#at91rm9200dk">Board Support for AT91RM9200DK</a></li>
		<li><a href="#at91rm9200ek">Board Support for AT91RM9200EK</a></li>
		<li><a href="#at91sam9g20ek">Board Support for AT91SAM9G20EK</a></li>
		<li><a href="#Minicom extensions">X-Modem/Raw extensions to minicom</a></li>
		<li><a href="#cmd_factory">New Command: factory</a></li>
		<li><a href="#cmd_os">New Command: os</a></li>
		<li><a href="#cmd_fs">New Command: fs</a></li>
		<li><a href="#cmd_setargs">New Command: setargs</a></li>
		<li><a href="#cmd_led">New Command: led</a></li>
		<li><a href="#cmd_mux">New Command: mux</a></li>
		<li><a href="#cmd_ethinit">New Command: ethinit</a></li>
		<li><a href="#environment">Special environment variables</a></li>
	</ul>
	<h2><a name="about" id="about"></a>About U-boot</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	U-Boot is an open source bootloader ported to a multitude of processors.
	See (<a href="http://www.denx.de/wiki/U-Boot/WebHome">U-Boot Home</a>)
	for documentation for vanilla U-Boot. This document only describes
	changes compared to the vanilla u-boot.
	</p>

	<h2><a name="at91rm9200dk" id="at91rm9200dk"></a>Board support for at91rm9200dk</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	"at91rm9200dk" is updated to use a linux like API for gpio.
	A new target "at91rm9200dk_df" is defined to support boot from dataflash.
	</p>

	<h2><a name="at91rm9200ek" id="at91rm9200ek"></a>Board support for at91rm9200ek</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	The "at91rm9200ek" BSP supports booting from a parallel flash.
	The "at91rm9200df" BSP supports a generic target booting from dataflash.
	</p>

	<h2><a name="#at91sam9g20ek" id="#at91sam9g20ek"></a>Board support for at91sam9g20ek</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	The "at91sam9g20ek" target with dataflash(card) and NAND boot support.
	</p>

	<h2><a name="minicom_extensions" id="minicom_extensions"></a>Minicom extensions </h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	"sx-at91" is a reliable X-Modem application allowing download to the at91rm9200
	based board
	</p>
	<p>
	"raw-at91" is a download application which will download binary data using minicom.
	Typically used to download an environment script.
	</p>

	<h2><a name="cmd_factory" id="cmd_factory"></a>New command: factory</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>factory</code></h3>
	</p>

	<p>
	"factory" will set a selected set of environment variables 
	back to the compile time default. The following will give some
	hints on capabilities, but is not yet complete.
	</p>

	<p>
	It will generate a set of scripts which will facilitate downloading
	the kernel and root file system using tftp and will also
	add commands to store into and retrieve from flash
	</p>

	<h2><a name="cmd_os" id="cmd_os"></a>New command: os</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>os<code></h3>
	</p>
	<p>
	"os" computes a new name for the linux kernel
	</p>

	<h2><a name="cmd_fs" id="cmd_fs"></a>New command: fs</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>fs<code></h3>
	</p>
	<p>
	"fs" computes a new name for the file system
	</p>

	<h2><a name="cmd_setargs" id="cmd_setargs"></a>New command: setargs</h2>
	<a href="#top"><small>[TOP]</small></a>
	<p>
	<h3><code>setargs<code></h3>
	</p>
	<p>
	"setargs" will create new bootcmd/bootargs combination from
	kernel name, filesystem name, and rootfs type.
	</p>

	<h2><a name="cmd_led" id="cmd_led"></a>New command: led</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>led [green | yellow | red | all ]  [ on | off ]<code></h3>
	</p>

	<p>
	"led" will turn on or off the specified (coloured) led
	</p>

	<h2><a name="cmd_mux" id="cmd_mux"></a>New command: mux</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>mux [spi | mmc ]<code></h3>
	</p>

	<p>
	"mux" will select how to use the flash card connector on the 
	at91rm9200dk or at91rm9200ek
	</p>

	<h2><a name="cmd_ethinit" id="cmd_ethinit"></a>New command: ethinit</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>ethinit<code></h3>
	</p>

	<p>
	"ethinit" can be used to delay the boot of linux, until a valid network
	connection has been established. This is useful if the machine is NFS mounting
	the root file system and both this machine and the NFS server are powering up
	simultaneously. The NFS server could take a lot longer to boot, and waiting
	for this to boot may be neccessary for proper operation.
	</p>

	<h2><a name="environment" id="environment"></a>Special environment variables</h2>
	<a href="#top"><small>[TOP]</small></a>

	<p>
	<h3><code>rd<code></h3>
	</p>
	<p>
	rd contains the name of the current root file system
	It is autmatically generated from <bold>ver</bold> and <bold>rd-1</bold>, <bold>rd-2</bold> etc.
	The "fs-date" is added at the end.
	</p>

	<p>
	<h3><code>ver<code></h3>
	</p>
	<p>
	You can handle a number of different root fs by defining <code>ver</code>.
	When running <code>fs</code> rd will be assigned from one of:
	<ul><code>rd-1, rd2, rd-3 ...<code></ul>
	</p>
	<p>
	By defining <code>ver</code> to a number you will
	select the appropriate disk name 
	</p>

	<p>
	<h3><code>fs-date<code></h3>
	</p>
	<p>
	"date" part of the root file system name
	</p>

	<p>
	<h3><code>linux<code></h3>
	</p>
	<p>
	linux contains the name of the current kernel.
	</p>
	<p>
	It is generated from several environment variables when <code>os</code> is run
	</p>
	<p>
	A typical name would be "at91sam9263ek-linux-2.6.28-20090105.gz"
	</p>

	<p>
	<h3><code>hostname<code></h3>
	</p>
	<p>
	"name" part of the kernel file name
	</p>

	<p>
	<h3><code>kernel-version<code></h3>
	</p>
	<p>
	"version" part of the kernel file name
	</p>

	<p>
	<h3><code>kernel-date<code></h3>
	</p>
	<p>
	"date" part of the kernel file name
	</p>

	<p>
	<h3><code>fstype [ ram | flash ]<code></h3>
	<p>
	You can have several file system types.
	bootargs is created depending on fstype..
	</p>

	<a href="#top"><small>[TOP]</small></a>

	</div>
<!--
	<a href="http://validator.w3.org/check?uri=referer"><img
	border="0" height="31" width="88"
	src="images/valid-html401.png"
	alt="Valid HTML"></img></a>
-->

</body>
</html>
Loading