u-boot/doc/README.sched
wdenk 3e38691e8f * 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
2003-04-05 00:53:31 +00:00

54 lines
1.8 KiB
Plaintext

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>