summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorwdenk <wdenk>2003-04-05 00:53:31 +0000
committerwdenk <wdenk>2003-04-05 00:53:31 +0000
commit3e38691e8f7aa0d9b498d76c7279ddec6e4946f3 (patch)
treebec2e661298847dc5bcf9335ef31259686e882e1 /doc
parent36c05a80ecbe3997abd9aa628a68dd6c0bacf681 (diff)
* Patch by Arun Dharankar, 4 Apr 2003:LABEL_2003_04_05_0300
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
Diffstat (limited to 'doc')
-rw-r--r--doc/I2C_Edge_Conditions9
-rw-r--r--doc/README.INCA-IP44
-rw-r--r--doc/README.idma2intr10
-rw-r--r--doc/README.sched53
4 files changed, 114 insertions, 2 deletions
diff --git a/doc/I2C_Edge_Conditions b/doc/I2C_Edge_Conditions
index 91557a3ca97..be7f1bee1f1 100644
--- a/doc/I2C_Edge_Conditions
+++ b/doc/I2C_Edge_Conditions
@@ -31,8 +31,13 @@ Notes
!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A IBM 4xx BUG!!!
This reset edge condition could possibly be present in every I2C
-controller and device available. We should probably have a bus reset
-function for all our target CPUs.
+controller and device available. For boards where a I2C bus reset
+function can be implemented a i2c_init_board() function should be
+provided and enabled by #define'ing CFG_I2C_INIT_BOARD in your
+board's config file. Note that this is NOT necessary when using the
+bit-banging I2C driver (common/soft_i2c.c) as this already includes
+the I2C bus reset sequence.
+
Many thanks to Bill Hunter for finding this serious BUG.
email to: <williamhunter@attbi.com>
diff --git a/doc/README.INCA-IP b/doc/README.INCA-IP
new file mode 100644
index 00000000000..517eec04012
--- /dev/null
+++ b/doc/README.INCA-IP
@@ -0,0 +1,44 @@
+
+Flash programming on the INCA-IP board is complicated because of the
+EBU swapping unit. A BDI2000 can be used for flash programming only
+if the EBU swapping unit is enabled; otherwise it will not detect the
+flash memory. But the EBU swapping unit is disadbled after reset, so
+if you program some code to flash with the swapping unit on, it will
+not be runnable with the swapping unit off.
+
+The consequence is that you have to write a pre-swapped image to
+flash using the BDI2000. A simple host-side tool "inca-swap-bytes" is
+provided in the "tools/" directory. Use it as follows:
+
+ bash$ ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+Note that the current BDI config file _disables_ the EBU swapping
+unit for the flash bank 0. To enable it, (this is required for the
+BDI flash commands to work) uncomment the following line in the
+config file:
+
+ ;WM32 0xb8000260 0x404161ff ; Swapping unit enabled
+
+and comment out
+
+ WM32 0xb8000260 0x004161ff ; Swapping unit disabled
+
+Alternatively, you can use "mm 0xb8000260 <value>" commands to
+enable/disable the swapping unit manually.
+
+Just for reference, here is the complete sequence of actions we took
+to install a U-Boot image into flash.
+
+ 1. ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+ 2. From BDI:
+
+ mm 0xb8000260 0x404161ff
+ erase 0xb0000000
+ erase 0xb0010000
+ prog 0xb0000000 /tftpboot/INCA/u-boot.bin.swp bin
+ mm 0xb8000260 0x004161ff
+ go 0xb0000000
+
+
+(C) 2003 Wolfgang Denk
diff --git a/doc/README.idma2intr b/doc/README.idma2intr
new file mode 100644
index 00000000000..1828b513025
--- /dev/null
+++ b/doc/README.idma2intr
@@ -0,0 +1,10 @@
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
+
+Attached is an IDMA example code for MPC8260/PPCBoot. I had tried to
+search around and could not find any for implementing IDMA, so
+implemented one. Its not coded in the best way, but works.
+
+Also, I was able to test the IDMA specific code under Linux also
+(with modifications). My requirement was to implement it for
+CompactFlash implemented in memory mode, and it works for it under
+PPCBoot and Linux.
diff --git a/doc/README.sched b/doc/README.sched
new file mode 100644
index 00000000000..3aa89e6d392
--- /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>