* Patch by Arun Dharankar, 4 Apr 2003:
  Add IDMA example code (tested on 8260 only)

* Add support for Purple Board (MIPS64 5Kc)

* Add support for MIPS64 5Kc CPUs

* Fix missing setting of "loadaddr" and "bootfile" on ARM and MIPS

* Patch by Denis Peter, 04 Apr 2003:
  - update MIP405-4 board

* Patches by Denis Peter, 03 April 2003:
  - fix PCI IRQs on MPL boards
  - fix two more un-relocated pointer problems

* Fix behaviour of "run" command:
  - print error message iv variable does not exist
  - terminate processing of arguments in case of error

* Patches by Peter Figuli, 10 Mar 2003
  - Add support for BTUART on PXA platform
  - Add support for WEP EP250 (PXA) board

* Fix flash problems on INCA-IP; add tool to allow bruning images  to
  flash using a BDI2000

* Implement fix for I2C Edge Conditions problem for all boards that
  use the bit-banging driver (common/soft_i2c.c)

* Add patches by Robert Schwebel, 31 Mar 2003:
  - csb226 board: bring in sync with innokom/memsetup.S
  - csb226 board: fix MDREFR handling
  - misc doc fixes / extensions
  - innokom board: cleanup, MDREFR fix in memsetup.S, config update
  - add BOOT_PROGRESS to armlinux.c
diff --git a/doc/README.sched b/doc/README.sched
new file mode 100644
index 0000000..3aa89e6
--- /dev/null
+++ b/doc/README.sched
@@ -0,0 +1,53 @@
+Notes on the scheduler in sched.c:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+  'sched.c' provides an very simplistic multi-threading scheduler.
+   See the example, function 'sched(...)', in the same file for its
+   API usage.
+
+   Until an exhaustive testing can be done, the implementation cannot
+   qualify as that of production quality. It works with the example
+   in 'sched.c', it may or may not work in other cases.
+
+
+Limitations:
+~~~~~~~~~~~~
+
+  - There are NO primitives for thread synchronization (locking,
+    notify etc).
+
+  - Only the GPRs and FPRs context is saved during a thread context
+    switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
+    etc) are NOT saved.
+
+  - The scheduler is NOT transparent to the user. The user
+    applications must invoke thread_yield() to allow other threads to
+    scheduler.
+
+  - There are NO priorities, and the scheduling policy is round-robin
+    based.
+
+  - There are NO capabilities to collect thread CPU usage, scheduler
+    stats, thread status etc.
+
+  - The semantics are somewhat based on those of pthreads, but NOT
+    the same.
+
+  - Only seven threads are allowed. These can be easily increased by
+    changing "#define MAX_THREADS" depending on the available memory.
+
+  - The stack size of each thread is 8KBytes. This can be easily
+    increased depending on the requirement and the available memory,
+    by increasing "#define STK_SIZE".
+
+  - Only one master/parent thread is allowed, and it cannot be
+    stopped or deleted. Any given thread is NOT allowed to stop or
+    delete itself.
+
+  - There NOT enough safety checks as are probably in the other
+    threads implementations.
+
+  - There is no parent-child relationship between threads. Only one
+    thread may thread_join, preferably the master/parent thread.
+
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>