Documentation update

3 files changed, 11 insertions, 116 deletions

diff --git a/Documentation/README b/Documentation/README
deleted file mode 100644
index 23b47ef6d5..0000000000
--- a/Documentation/README
+++ /dev/null
@@ -1,107 +0,0 @@
-
-For long time U-Boot has served as a reliable and versatile bootloader for
-embedded systems, but over the time more and more limitations appeared.
-With U-Boot one hasd to know the memory layout of a particular device to work
-with it. For example to use tftpboot you need to know a memory address where
-you can store the file you are just loading. Saving it in flash requires you
-to know where in the memory space your flash device is and what erase block
-size it has. Configuring U-Boot means that you handle a lot of #defines. This
-usually starts with one define to activate a feature, compiling U-Boot and
-letting the compiler tell you what other defines you'll probably need.
-
-This is an attempt to rework U-Boot to fit the needs of modern embedded
-systems. Features include:
-
-- A posix based file API
-  inside U-Boot the usual open/close/read/write/lseek functions are used.
-  This makes it familiar to everyone who has programmed under unix systems.
-
-- usual shell commands like ls/cd/mkdir/echo/cat,...
-
-- The environment is not a variable store anymore, but a file store. It has
-  currently some limitations, of course. The environment is not a real
-  read/write filesystem, it is more like a tar archive, or even more like
-  an ar archive, because it cannot handle directories. The saveenv command
-  saves the files under a certain directory (by default /env) in persistent
-  storage (by default /dev/env0). There is a counterpart called loadenv, too.
-
-- Real filesystem support
-  The loader starts up with mounting a ramdisk on /. Then a devfs is mounted
-  on /dev allowing the user (or shell commands) to access devices. Apart from
-  these two filesystems there is currently one filesystem ported: cramfs. One
-  can mount it with the usual mount command.
-
-- device/driver model
-  Devices are no longer described by defines in the config file. Instead
-  there are devices which can be registered in the board .c file or
-  dynamically allocated. Drivers will match upon the devices automatically.
-
-- clocksource support
-  Timekeeping has been simplified by the use of the Linux clocksource API.
-  Only one function is needed for a new board, no [gs]et_timer[masked]() or
-  reset_timer[masked]() functions.
-
-- Kconfig and Kernel build system
-  Only targets which are really needed get recompiled. Parallel builds are
-  no problem anymore. This also removes the need for many many ifdefs in
-  the code.
-
-- simulation target
-  U-Boot can be compiled to run under Linux. While this is rather useless
-  in real world this is a great debugging and development aid. New features
-  can be easily developped and tested on long train journeys and started
-  under gdb. There is a console driver for linux which emulates a serial
-  device and a tap based ethernet driver. Linux files can be mapped to
-  devices under U-Boot to emulate storage devices.
-
-- device parameter support
-  Each device can have a unlimited number of parameters. They can be accessed
-  on the command line with <devid>.<param>="...", for example
-  'eth0.ip=192.168.0.7' or 'echo $eth0.ip'
-
-- initcalls
-  hooks in the startup process can be archieved with *_initcall() directives
-  in each file.
-
-- getopt
-  There is a small getopt implementation. Some commands got really
-  complicated (both in code and in usage) due to the fact that U-Boot only
-  allowed positional parameters.
-
-- editor
-  Scripts can be edited with a small editor. This editor has no features
-  except the ones really needed: moving the cursor and typing characters.
-
-To get started try
-
-ARCH=linux make linux_defconfig
-ARCH=linux make menuconfig
-ARCH=linux make
-./vmlinux
-
-(you can also do a 'ln -s linux cross_arch' to specify ARCH, the Makefile
-will read the link. Same with 'ln -s arm cross_compile', for example)
-
-This will currently only work on an IA32 architecture, because of some
-hardcoded values in the linker script because and little endian is assumed.
-Starting U-Boot as root will give you a new tap device which you can
-configure with
-
-ifconfig tap0 172.0.0.1 up
-
-After setting the network parameters under U-Boot (see 'devinfo eth0') you
-can start with sending a ping request to your host. If you have a tftp
-server running on your host try 'tftpboot <somefile> /target_file'
-
-For informations on how to map a file to U-Boot try ./vmlinux -h.
-For example if you wish to map a cramfs image to u-boot you can generate one
-with mkcramfs <dir> cramfs.bin and then start U-Boot with -i cramfs.bin. The
-image can be mounted with 'mkdir /cram; mount /dev/fd0 cramfs /cram'
-
-Still reading?
-Well, of course I only talked about the sunny side of life. This stuff is
-highly experimental. The code has so far only been tested under ARM and
-partly under PowerPC. On PowerPC This loader is not even able to start a
-kernel. Much work has to be done until this becomes a usable bootloader.
-Despite this I believe this _can_ become usable with reasonable effort.
-... to be continued
diff --git a/Documentation/parameters.txt b/Documentation/parameters.txt
index 219440b40c..9381cd2d3e 100644
--- a/Documentation/parameters.txt
+++ b/Documentation/parameters.txt
@@ -33,7 +33,7 @@ with the initial value of the parameter. If the framework handles the set
 function it will try to free the value of the parameter. If this is a
 static array bad things will happen. A parameter can have the flag
 PARAM_FLAG_RO which means that the parameter is readonly. It is perfectly ok
-then to point value to a static array.
+then to point the value to a static array.
 
 const char *dev_get_param(struct device_d *dev, const char *name);
 
diff --git a/Documentation/porting.txt b/Documentation/porting.txt
index adbbb6ce5b..7cc3bc298a 100644
--- a/Documentation/porting.txt
+++ b/Documentation/porting.txt
@@ -46,6 +46,8 @@ static int scb9328_console_init(void)
 	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.
 
@@ -54,8 +56,6 @@ static int scb9328_console_init(void)
   This will add an area starting at 0x40000 of size 0x20000 of the device
   cfi_dev as env0.
 
-console_initcall(scb9328_console_init);
-
 - Port missing drivers. Depending on the driver this can a be rather simple
   process:
 
@@ -68,11 +68,13 @@ console_initcall(scb9328_console_init);
   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 fields in struct eth_device. get_mac_address() shall retrieve the
-    MAC address from the EEPROM if one is connected. If you don't have an
-    EEPROM just return -1. set_mac_address() shall set the MAC address in
-    the device. All magic previously done with getenv/setenv(ethaddr) must be
-    removed.
+    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 U-Boot 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
@@ -118,4 +120,4 @@ calc_source:
   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.
+  arch/arm/cpu. The start.S files are missing though.