Documentation: remove remaining documentation

This removes the documentation texts in Documentation/. It will
be replaced with sphinx based documentation later.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

5 files changed, 0 insertions, 240 deletions

diff --git a/Documentation/console.txt b/Documentation/console.txt
deleted file mode 100644
index 76b6107ac6..0000000000
--- a/Documentation/console.txt
+++ /dev/null
@@ -1,13 +0,0 @@
--------------- barebox consoles ------------------
-
-barebox supports multiple consoles which may be simultaneously active.
-Depending on the configuration none, the first or all consoles are
-activated on startup, see CONSOLE_ACTIVATE_FIRST and CONSOLE_ACTIVATE_ALL
-options.
-
-During runtime the behaviour of the consoles can be controlled with the
-'active' parameter each console has. The console system recognizes three
-characters: 'i' for stdin, 'o' for stdout and 'e' for stderr. These options
-may be concatenated together as needed, so setting an 'active' parameter
-of a console to 'io' would enable it for stdout and stdin while leaving
-stderr disabled.
diff --git a/Documentation/devices_drivers.txt b/Documentation/devices_drivers.txt
deleted file mode 100644
index e13b13a52f..0000000000
--- a/Documentation/devices_drivers.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-
----------- Devices and drivers in barebox --------------
-
-We follow a rather simplistic driver model here. There is a struct device which
-describes a particular device present in the system. A struct driver represents
-a driver present in the system. Both structs find together via the members
-'type' (int) and 'name' (char *). If both members match, the driver's probe
-function is called with the struct device as argument. People familiar with
-the Linux platform bus will recognize this behaviour and in fact many things were
-stolen from there. Some selected members of the structs will be described in this
-document.
-Currently all devices and drivers are handled in simple linked lists. When it comes
-to USB or PCI it may be desirable to have a tree structure, but this may also be
-unnecessary overhead.
-
-struct device
--------------
-
-char name[MAX_DRIVER_NAME];
-
-This member (and 'type' described below) is used to match with a driver. This is
-a descriptive name and could be MPC5XXX_ether or imx_serial.
-
-char id[MAX_DRIVER_NAME];
-
-The id is used to uniquely identify a device in the system. The id will show up
-under /dev/ as the device's name. Usually this is something like eth0 or nor0.
-
-void *type_data;
-
-Devices of a particular class normaly need to store more information than struct
-device holds. This entry holds a pointer to the type specific struct.
-
-void *priv;
-
-Used by the device driver to store private information.
-
-void *platform_data;
-
-This is used to carry information of board specific data from the board code to the
-device driver.
-
-struct param_d *param;
-
-The parameters for this device. See Documentation/parameters.txt for more info.
-
-struct driver_d
----------------
-
-char name[MAX_DRIVER_NAME];
-unsigned long type;
-
-See above.
-
-int     (*probe) (struct device_d *);
-int     (*remove)(struct device_d *);
-
-These are called if an instance of a device is found or gone.
-
-ssize_t (*read)  (struct device_d*, void* buf, size_t count, ulong offset, ulong flags);
-ssize_t (*write) (struct device_d*, const void* buf, size_t count, ulong offset, ulong flags);
-
-The standard read/write functions. These are called as a response to the read/write
-system calls. No driver needs to implement these.
-
-void *type_data;
-
-This is somewhat redundant with the type data in struct device. Currently the
-filesystem implementation uses this field while ethernet drivers use the same
-field in struct device. Probably one of them should be removed.
-
-
diff --git a/Documentation/omap4_usb_booting.txt b/Documentation/omap4_usb_booting.txt
deleted file mode 100644
index f0d45a2aa1..0000000000
--- a/Documentation/omap4_usb_booting.txt
+++ /dev/null
@@ -1,27 +0,0 @@
--------------- omap4_usb_booting --------------
-
-omap4 processors have support for booting from the usb port. To be able to fully
-use this feature you will need to enable the following:
-    OMAP4_USBBOOT
-        This CONFIG_ option adds the required infrastructure.
-    DRIVER_SERIAL_OMAP4_USBBOOT
-        This adds console support over the same usb port used for booting.
-    FS_OMAP4_USBBOOT
-        This adds filesystem support over the same usb port used for booting.
-
-To send the bootloader to the processor, execute the utility omap4_usbboot which
-can be found in the scripts subdirectory.
-omap4_usbboot takes two parameters:
-    the bootloader image
-    a directory name which will be the root for the guest system
-Once omap4_usbboot is running it will wait for enumeration of the omap4 cpu on
-the host usb subsystem. Then power on or reset the cpu with the correct sys_boot
-or SAR memory configuration.
-
-If everything works, barebox's first stage will boot and afterwards it will load
-the second stage found at "/barebox.bin".
-Barebox's second stage will still have access to the usb filesystem, so an
-initrd and a zImage can be loaded.
-
-Overall this procedure frees the developer of continously be changing the SD
-card or other boot media from host to target.
diff --git a/Documentation/porting.txt b/Documentation/porting.txt
deleted file mode 100644
index bd807a3186..0000000000
--- a/Documentation/porting.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-
-When porting from old barebox the follwing steps must be taken (please complain
-if there's something missing here ;)
-
-
-- Most of the macros in include/configs/yourboard.h can be removed, especially
-  the CONFIG_COMMANDS section. The goal is to remove this file entirely, but
-  for now some values are still needed here. If you think some things are better
-  configured with the Kconfig system feel free to add them there.
-
-- The linker script needs a new section for the initcalls. The handling of the
-  barebox command table has changed, too. (The commands are now sorted by the
-  linker instead at runtime.) To change it you need an entry like the following
-  in your linker script:
-
-#include <asm-generic/barebox.lds.h>
-
-	__barebox_cmd_start = .;
-	.barebox_cmd : { BAREBOX_CMDS }
-	__barebox_cmd_end = .;
-
-	__barebox_initcalls_start = .;
-	.barebox_initcalls : { INITCALLS }
-	__barebox_initcalls_end = .;
-
-- Rename your linker script to barebox.lds.S and add the following entry to the
-  Makefile to make sure the linker script is generated:
-
-extra-y += barebox.lds
-
-- Register the devices present in your system in the board specific .c file.
-  To see anything you have to at least register a console. In scb9328.c this
-  looks like this:
-
-	static struct device_d scb9328_serial_device = {
-		.name     = "imx_serial",
-		.map_base = IMX_UART1_BASE,
-		.size     = 4096,
-	};
-
-	static int scb9328_console_init(void)
-	{
-		platform_device_register(&scb9328_serial_device);
-		return 0;
-	}
-
-	console_initcall(scb9328_console_init);
-
-- For most boards you will have to register a cfi_flash device. NAND flash
-  is not ported yet.
-
-- Call devfs_add_partition() to add an environment partition for your device:
-  devfs_add_partition("nor0", 0x40000, 0x20000, DEVFS_PARTITION_FIXED, "env0");
-  This will add an area starting at 0x40000 of size 0x20000 of the device
-  nor0 as env0.
-
-- Port missing drivers. Depending on the driver this can a be rather simple
-  process:
-
-  Serial drivers
-  - Declare all functions static.
-  - in your probe function fill in a struct console_device and register it
-    with console_register()
-
-  Ethernet drivers
-  - Basically do the same as with serial drivers.
-  - Identify the parts of the driver which handle the MAC address. There are
-    now two functions handling them in struct eth_device. 
-
-    get_mac_address() retrieve the MAC address from the EEPROM if one is
-                      connected. If you don't have an EEPROM just return -1.
-    set_mac_address() set the MAC address in the device. All magic previously
-                      done with getenv/setenv(ethaddr) must be removed.
-
-    During startup barebox calls get_mac_address() to see if an EEPROM is
-    connected. If so, it calls set_mac_address() with this address. This
-    is done even if networking is not used during startup. This makes sure
-    that the MAC address is set in the device and Linux can pick it up later.
-  - There is now (the beginning of) generic phy support. When porting drivers
-    it is recommended to use it. The phy support currently only starts generic
-    autonegotiation, so if you have some fancy things to do (or have gigabit
-    ethernet) you'll have to extend the phy layer first. Although this is
-    extra work, it will pay off some day, as phy support is a great source
-    of duplicated code. see drivers/net/dm9000.c or drivers/net/fec_mpc5200.c
-    for examples.
-
-- Add a clocksource for your system. PowerPCs have a generic decrementer
-  counter, so if you have a PowerPC you have nothing to do here. On ARM
-  this is SoC dependent. See Documentation/timekeeping.txt for further
-  information.
-
-- Adjust start.S. On PowerPC there is at least the Problem that the relocation
-  offset is defined at compile time. It is easily possible to determine the
-  address barebox is currently starting from at runtime and thus allowing it
-  barebox to be started at any address. Look at the relocation code and replace
-  TEXT_BASE with the following calculation of the runtime address:
-
-	bl     calc_source     /* Calculate Source Address             */
-calc_source:
-	mfspr   r4,  LR
-	subi    r4, r4, (calc_source - _start)
-	subi    r4, r4, 0x100
-
-  (I'm almost sure that PowerPC has a dedicated instruction for this, un-
-  fortunately I know next to nothing of PowerPC assembler, so if you have
-  a better way to archieve this, please write to the list.)
-
-  On PowerPC barebox now runs at the address it was linked to, so you have
-  to adjust TEXT_BASE to be in RAM. This makes the various fixup relocation
-  functions unnecessary. On PowerPC the removal of -fPIC saves around 10% of
-  binary space. It also simplifies debugging because you will see the correct
-  addresses in the objdump without doing offset calculation.
-
-- On ARM most of the duplicate code under cpu/arm* is already merged into
-  arch/arm/cpu. The start.S files are missing though.
diff --git a/Documentation/timekeeping.txt b/Documentation/timekeeping.txt
deleted file mode 100644
index ed5ef62fe0..0000000000
--- a/Documentation/timekeeping.txt
+++ /dev/null
@@ -1,13 +0,0 @@
------------- barebox timekeeping -------------
-
-In barebox we use the clocksource mechanism from the Linux Kernel. This makes
-it fairly easy to add timer functionality for a new board or architecture.
-Apart from initialization there is only one function required:
-clocksource_read(). This function returns the current value of a free running
-counter. Other functions like udelay() and get_time_ns() are derived from this
-function. The only thing you have to implement is a clocksource driver. See
-cpu/arm920t/imx/interrupts.c for an example. clocksource drivers from the
-Linux Kernel can be used nearly 1:1, except for the register accesses.
-
-for clocksources the __lshrdi3 symbol is needed. You can find the function for
-your architecture in the Linux Kernel or a libc of your choice.