diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/I2C_Edge_Conditions | 9 | ||||
| -rw-r--r-- | doc/README.INCA-IP | 44 | ||||
| -rw-r--r-- | doc/README.idma2intr | 10 | ||||
| -rw-r--r-- | doc/README.sched | 53 | 
4 files changed, 114 insertions, 2 deletions
| diff --git a/doc/I2C_Edge_Conditions b/doc/I2C_Edge_Conditions index 91557a3ca..be7f1bee1 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 000000000..517eec040 --- /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 000000000..1828b5130 --- /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 000000000..3aa89e6d3 --- /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> |