sysmo-bts
/
barebox
9
0
Fork 0
Code Releases Activity

remove outdated documentation

This commit is contained in:
Sascha Hauer 2007-09-21 14:19:13 +02:00
parent 9414ad39af
commit 9b06273fc9
90 changed files with 0 additions and 12404 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/I2C_Edge_Conditions
View File

@ -1,46 +0,0 @@
I2C Edge Conditions:
====================
I2C devices may be left in a write state if a read was occuring
and the CPU was reset. This may result in EEPROM data corruption.
The edge condition is as follows:
1) A read operation begins.
2) I2C controller issues a start command.
3) The I2C writes the device address.
4) The CPU is reset at this point.
Once the CPU reinitializes and the read is tried again:
1) The I2C controller issues a start command.
2) The I2C controller writes the device address.
3) The I2C controller writes the offset.
The EEPROM sees:
1) START
2) device address
3) START "this start is ignored by most EEPROMs"
4) device address "EEPROM interprets this as offset"
5) Offset in device, "EEPROM interprets this as data to write"
The device will interpret this sequence as a WRITE command and
write rubbish into itself, i.e. the "offset" will be interpreted
as data to be written in location "device address".
Notes
-----
!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A AMCC 4xx BUG!!!
This reset edge condition could possibly be present in every I2C
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>
Erik Theisen <etheisen@mindspring.com>
Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET)

74
doc/README-i386
View File

@ -1,74 +0,0 @@
This is my attempt to port U-Boot to the i386 platform. This
work was sponsored by my emplyer, Omicron Ceti AB. http://www.omicron.se
It is currently capable of booting a linux bzImage from flash on
the AMD SC520 CDP platform.
It was originally based on PPCBoot taken from the CVS October 28 2002.
To compile:
1) Unpack the source tree, either from the complete tarball or
from the virgin snapshot + the patch
2) Configure the source
$ make sc520_cdp_comfig
$ make
To use this code on the CDP:
1) Make a suitable kernel, I used 2.4.19 with the mtd-support updated
from the MTD CVS and a patch to allow root=/dev/mtdblock1 which I
included at the end of this file.
The following options in the MTD section might be useful:
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=38100000
CONFIG_MTD_PHYSMAP_LEN=7a0000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
2) Program it in to the CDP flashbank with remon
u-boot.bin should be programmed att offset 0x7e000 and the kernel at
offset 0. If you want to use a jffs2 root file system (not included here),
it should be programmed to offset 0x100000.
remon> z
remon> yi
remon> ns u-boot.bin 7e0000
remon> ns bzImage 0
remon> ns image.jffs2 100000
3) Connect a terminal to the 25pin serial port at 9600bps, and start the CDP.
remon> z
remon> g
4) U-Boot should output some message and a prompt on the terminal, to
start the kernel issue the following command:
BOOT> bootm
5) The kernel should boot, and mount the root filesystem if present.
We hope you find this stuff useful
Daniel Engström, Omicron Ceti AB, daniel@omicron.se
--- linux-2.4.19-orig/init/do_mounts.c Sat Aug 3 02:39:46 2002
+++ linux-2.4.19/init/do_mounts.c Mon Sep 23 16:21:33 2002
@@ -224,6 +224,14 @@
{ "ftlc", 0x2c10 },
{ "ftld", 0x2c18 },
{ "mtdblock", 0x1f00 },
+ { "mtdblock0", 0x1f00 },
+ { "mtdblock1", 0x1f01 },
+ { "mtdblock2", 0x1f02 },
+ { "mtdblock3", 0x1f03 },
+ { "mtdblock4", 0x1f04 },
+ { "mtdblock5", 0x1f05 },
+ { "mtdblock6", 0x1f06 },
+ { "mtdblock7", 0x1f07 },
{ NULL, 0 }
};
-------------------

110
doc/README-integrator
View File

@ -1,110 +0,0 @@
U-Boot for ARM Integrator Development Platforms
Peter Pearse, ARM Ltd.
peter.pearse@arm.com
www.arm.com
Manuals available from :-
http://www.arm.com/products/DevTools/Hardware_Platforms.html
Overview :
--------
There are two Integrator variants - Integrator/AP and Integrator/CP.
Each may be fitted with a variety of core modules (CMs).
Each CM consists of a ARM processor core and associated hardware e.g
FPGA implementing various controllers and/or register
SSRAM
SDRAM
RAM controllers
clock generators etc.
CMs may be fitted with varying amounts of SDRAM using a DIMM socket.
Boot Methods :
------------
Integrator platforms can be configured to use U-Boot in at least three ways :-
a) Run ARM boot monitor, manually run U-Boot image from flash
b) Run ARM boot monitor, automatically run U-Boot image from flash
c) Run U-Boot image direct from flash.
In cases a) and b) the ARM boot monitor will have configured the CM and mapped
writeable memory to 0x00000000 in the Integrator address space.
U-Boot has to carry out minimal configration before standard code is run.
In case c) it may be necessary for U-Boot to perform CM dependent initialization.
Configuring U-Boot :
------------------
The makefile contains targets for Integrator platforms of both types
fitted with all current variants of CM. If these targets are to be used with
boot process c) above then CONFIG_INIT_CRITICAL may need to be defined to ensure
that the CM is correctly configured.
There are also targets independent of CM. These may not be suitable for
boot process c) above. They have been preserved for backward compatibility with
existing build processes.
Code Hierarchy Applied :
----------------------
Code specific to initialization of a particular ARM processor has been placed in
cpu/arm<>/start.S so that it may be used by other boards.
However, to avoid duplicating code through all processor files, a generic core
for ARM Integrator CMs has been added
cpu/arm_intcm
Otherwise. for example, the standard CM reset via the CM control register would
need placing in each CM processor file......
Code specific to the initialization of the CM, rather than the cpu, and initialization
of the Integrator board itself, has been placed in
board/integrator<>/platform.S
board/integrator<>/integrator<>.c
Targets
=======
The U-Boot make targets map to the available core modules as below.
Integrator/AP is no longer available from ARM.
Core modules marked ** are also no longer available.
ap720t_config ** CM720T
ap920t_config ** CM920T
ap926ejs_config Integrator Core Module for ARM926EJ-STM
ap946es_config Integrator Core Module for ARM946E-STM
cp920t_config ** CM920T
cp926ejs_config Integrator Core Module for ARM926EJ-STM
cp946es_config Integrator Core Module for ARM946E-STM
cp1136_config Integrator Core Module ARM1136JF-S TM
The final groups of targets are for core modules where no explicit cpu
code has yet been added to U-Boot i.e. they all use the same U-Boot binary
using the generic "arm_intcm" core:
ap966_config Integrator Core Module for ARM966E-S TM
ap922_config Integrator Core Module for ARM922T TM with ETM
ap922_XA10_config Integrator Core Module for ARM922T using Altera Excalibur
ap7_config ** CM7TDMI
integratorap_config
ap_config
cp966_config Integrator Core Module for ARM966E-S TM
cp922_config Integrator Core Module for ARM922T TM with ETM
cp922_XA10_config Integrator Core Module for ARM922T using Altera Excalibur
cp1026_config Integrator Core Module ARM1026EJ-S TM
integratorcp_config
cp_config
The Makefile targets call board/integrator<>/split_by_variant.sh
to configure various defines in include/configs/integrator<>.h
to indicate the core module & core configuration and ensure that
board/integrator<>/u-boot.lds loads the cpu object first in the U-Boot image.
*********************************
Because of this mechanism
> make clean
must be run before each change in configuration
*********************************

90
doc/README.440-DDR-performance
View File

@ -1,90 +0,0 @@
AMCC suggested to set the PMU bit to 0 for best performace on the
PPC440 DDR controller. The 440er common DDR setup files (sdram.c &
spd_sdram.c) are changed accordingly. So all 440er boards using
these setup routines will automatically receive this performance
increase.
Please see below some benchmarks done by AMCC to demonstrate this
performance changes:
----------------------------------------
SDRAM0_CFG0[PMU] = 1 (U-boot default for Bamboo, Yosemite and Yellowstone)
----------------------------------------
Stream benchmark results
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 2000000, Offset = 0
Total memory required = 45.8 MB.
Each test is run 10 times, but only
the *best* time for each is used.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 112345 microseconds.
(= 112345 clock ticks)
Increase the size of the arrays if this shows that you are not getting
at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the precision of your system
timer.
-------------------------------------------------------------
Function Rate (MB/s) RMS time Min time Max time
Copy: 256.7683 0.1248 0.1246 0.1250
Scale: 246.0157 0.1302 0.1301 0.1302
Add: 255.0316 0.1883 0.1882 0.1885
Triad: 253.1245 0.1897 0.1896 0.1899
TTCP Benchmark Results
ttcp-t: socket
ttcp-t: connect
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp ->
localhost
ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++
ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57
ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw
----------------------------------------
SDRAM0_CFG0[PMU] = 0 (Suggested modification)
Setting PMU = 0 provides a noticeable performance improvement *2% to
5% improvement in memory performance.
*Improves the Mbit/sec for TTCP benchmark by almost 76%.
----------------------------------------
Stream benchmark results
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 2000000, Offset = 0
Total memory required = 45.8 MB.
Each test is run 10 times, but only
the *best* time for each is used.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 120066 microseconds.
(= 120066 clock ticks)
Increase the size of the arrays if this shows that you are not getting
at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the precision of your system
timer.
-------------------------------------------------------------
Function Rate (MB/s) RMS time Min time Max time
Copy: 262.5167 0.1221 0.1219 0.1223
Scale: 258.4856 0.1238 0.1238 0.1240
Add: 262.5404 0.1829 0.1828 0.1831
Triad: 266.8594 0.1800 0.1799 0.1802
TTCP Benchmark Results
ttcp-t: socket
ttcp-t: connect
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp ->
localhost
ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++
ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89
ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw
2006-07-28, Stefan Roese <sr@denx.de>

31
doc/README.AMCC-eval-boards-cleanup
View File

@ -1,31 +0,0 @@
---------------------------------------------------------------------
Cleanup of AMCC eval boards (Walnut/Sycamore, Bubinga, Ebony, Ocotea)
---------------------------------------------------------------------
Changes to all AMCC eval boards:
--------------------------------
o Changed u-boot image size to 256 kBytes instead of 512 kBytes on most
boards.
o Use 115200 baud as default console baudrate.
o Added config option to use redundant environment in flash. This is also
the default setting. Option for environment in nvram is still available
for backward compatibility.
o Merged board specific flash drivers to common flash driver:
board/amcc/common/flash.c
Sycamore/Walnut (one port supporting both eval boards):
-------------------------------------------------------
o Cleanup to allow easier "cloning" for different (custom) boards:
o Moved EBC configuration from board specific asm-file "init.S"
using defines in board configuration file. No board specific
asm file needed anymore.
August 01 2005, Stefan Roese <sr@denx.de>

31
doc/README.ARM-SoC
View File

@ -1,31 +0,0 @@
[By Steven Scholz <steven.scholz@imc-berlin.de>, 16 Aug 2004]
Since the cpu/ directory gets clobbered with peripheral driver code I
started cleaning up cpu/arm920t.
I introduced the concept of Soc (system on a chip) into the ./cpu
directory. That means that code that is cpu (i.e. core) specific
resides in
cpu/$(CPU)/
and code that is specific to some SoC (i.e. vendor specific
peripherals around the core) is moved into
cpu/$(CPU)/$(SOC)/
Thus a library/archive "cpu/$(CPU)/$(SOC)/lib$(SOC).a" will be build
and linked. Examples will be
cpu/arm920t/imx/
cpu/arm920t/s3c24x0
One can select an SoC by passing the name of it to ./mkconfig just
like
@./mkconfig $(@:_config=) arm arm920t vcma9 mpl s3c24x0
If there's no VENDOR field (like "mpl" in the above line) one has to
pass NULL instead:
@./mkconfig $(@:_config=) arm arm920t mx1ads NULL imx

17
doc/README.ARM-memory-map
View File

@ -1,17 +0,0 @@
Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour
From: "Anders Larsen" <alarsen@rea.de>
Date: Thu, 18 Sep 2003 14:15:21 +0200
To: Wolfgang Denk <wd@denx.de>
...
>I still see references to _armboot_start, _armboot_end_data, and
>_armboot_end - which role do these play now? Can we get rid of them?
>
>How are they (should they be) set in your memory map above?
_armboot_start contains the value of TEXT_BASE (0xA07E0000); it seems
TEXT_BASE and _armboot_start are both used for the same purpose in
different parts of the (ARM) code.
Furthermore, the startup code (cpu/<arm>/start.S) internally uses
another variable (_TEXT_BASE) with the same content as _armboot_start.
I agree that this mess should be cleaned up.

33
doc/README.AVR32
View File

@ -1,33 +0,0 @@
From: Haavard Skinnemoen <hskinnemoen@atmel.com>
Date: Wed, 30 Aug 2006 17:01:46 +0200
Subject: [PATCH] AVR32 architecture support
This patch adds common infrastructure code for the Atmel AVR32
architecture.
AVR32 is a new high-performance 32-bit RISC microprocessor core,
designed for cost-sensitive embedded applications, with particular
emphasis on low power consumption and high code density. The AVR32
architecture is not binary compatible with earlier 8-bit AVR
architectures.
The AVR32 architecture, including the instruction set, is described
by the AVR32 Architecture Manual, available from
http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf
A GNU toolchain with support for AVR32 is included with the ATSTK1000
BSP, which can be downloaded as an ISO image from
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918
Alternatively, you can build it yourself by following the
Getting Started guide at avr32linux.org, which also provides links
to the necessary sources and patches you need to download:
http://avr32linux.org/twiki/bin/view/Main/GettingStarted
The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and
other associated software are actively supported by Atmel Corporation.
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>

156
doc/README.COBRA5272
View File

@ -1,156 +0,0 @@
File: README.COBRA5272
Author: Florian Schlote for Sentec elektronik (linux@sentec-elektronik.de)
Contents: This is the README of u-boot (Universal bootloader) for our
COBRA5272 board.
Version: v01.00
Date: Tue Mar 30 00:28:33 CEST 2004
License: This document is published under the GNU GPL
______________________________________________________________________
CHANGES
040330 v01.00 Creation
______________________________________________________________________
CONFIGURING
-----------
1. Modify include/configs/cobra5272.h acc. to your prefs
2. If necessary, modify board/cobra5272/config.mk (see below)
3.
> make cobra5272_config
> make
Please refer to u-boot README (general info, u-boot-x-x-x/README),
to u-boot-x-x-x/doc/README.COBRA5272 and
to the comments in u-boot-x-x-x/include/configs/cobra5272.h
Configuring u-boot is done by commenting/uncommenting preprocessor defines.
Default configuration is
FLASH version (for further info see subsection below)
link address 0xffe00000
16 MB RAM
network enabled
no default IP address for target, host set, no MACaddress set
bootdelay for autoboot 5 sec.
autoboot disabled
#-----------------------------------
# u-boot FLASH version & RAM version
#-----------------------------------
The u-boot bootloader for Coldfire processors can be configured
1. as a standalone bootloader residing in flash & relocating itself to RAM on
startup automatically => "FLASH version"
2. as a RAM version which will not load from flash automatically as it needs a
prestage bootloader ("chainloading") & is running only from the RAM address it
is linked to => "RAM version"
This version may be very helpful when installing u-boot for the first time
since it can be used to make available s. th. like a "bootstrap
mechanism".
How to build the different images:
------------------------------
Flash version
------------------------------
Compile u-boot
in dir ./u-boot-x-x-x/
please first check:
in ./include/configs/cobra5272.h
CONFIG_MONITOR_IS_IN_RAM has to be undefined, e. g. as follows:
#if 0
#define CONFIG_MONITOR_IS_IN_RAM
/* define if monitor is started from a pre-loader */
#endif
=> u-boot as single bootloader starting from flash
in board/cobra5272/config.mk TEXT_BASE should be
TEXT_BASE = 0xffe00000
=> linking address for u-boot as single bootloader stored in flash
then:
host> make cobra5272_config
rm -f include/config.h include/config.mk
Configuring for cobra5272 board...
host> make
[...]
host> cp u-boot.bin /tftpboot/u-boot_flash.bin
------------------------------
RAM version
------------------------------
in dir ./u-boot-x-x-x/
host> make distclean
please modify the settings:
in ./include/configs/cobra5272.h
CONFIG_MONITOR_IS_IN_RAM now has to be defined, e. g. as follows:
#if 1
#define CONFIG_MONITOR_IS_IN_RAM
/*define if monitor is started from a pre-loader */
#endif
=> u-boot as RAM version, chainloaded by another bootloader or using bdm cable
in board/cobra5272/config.mk TEXT_BASE should be
TEXT_BASE = 0x00020000
=> target linking address for RAM
then:
host> make cobra5272_config
rm -f include/config.h include/config.mk
Configuring for cobra5272 board...
host> make
[...]
host> cp u-boot.bin /tftpboot/u-boot_ram.bin
----
HINT
----
If the m68k-elf-toolchain & the m68k-bdm-gdb is installed you can run the RAM
version by typing (in dir ./u-boot-x-x-x/)
"board/cobra5272/bdm/load-cobra_uboot" ,
in ./u-boot-x-x-x/ the RAM version u-boot (elf format) has to be available.

7
doc/README.EVB-64260-750CX
View File

@ -1,7 +0,0 @@
The EVB-64260-750CX is quite similar to the EVB-64260-BP already
supported except the following differences:
* It has an IBM-750CXe soldiered on board instead of the slot-1 in the
BP.
* It has a single PCI male connector instead of the 4 PCI female
connectors on the BP. It also gets power trough the PCI connector.
* It has only a single DIMM slot instead of the 2 slots in the BP.

57
doc/README.INCA-IP
View File

@ -1,57 +0,0 @@
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
Ethernet autonegotiation needs some time to complete. Instead of
delaying the boot process in all cases, we just start the
autonegotiation process when U-Boot comes up and that is all. Most
likely, it will complete by the time the network transfer is
attempted for the first time. In the worst case, if a transfer is
attempted before the autonegotiation is complete, just a single
packet would be lost resulting in a single timeout error, and then
the transfer would proceed normally. So the time that we would have
lost unconditionally waiting for the autonegotiation to complete, we
have to wait only if the file transfer is started immediately after
reset. We've verified that this works for all the clock
configurations.
(C) 2003 Wolfgang Denk

358
doc/README.IPHASE4539
View File

@ -1,358 +0,0 @@
This file contains basic information on the port of U-Boot to IPHASE4539
(Interphase 4539 T1/E1/J1 PMC Communications Controller).
All the changes fit in the common U-Boot infrastructure, providing a new
IPHASE4539-specific entry in makefiles. To build U-Boot for IPHASE4539,
type "make IPHASE4539_config", edit the "include/config_IPHASE4539.h"
file if necessary, then type "make".
Common file modifications:
--------------------------
The following common files have been modified by this project:
(starting from the ppcboot-1.1.5/ directory)
MAKEALL - IPHASE4539 entry added
Makefile - IPHASE4539_config entry added
New files:
----------
The following new files have been added by this project:
(starting from the ppcboot-1.1.5/ directory)
board/iphase4539/ - board-specific directory
board/iphase4539/Makefile - board-specific makefile
board/iphase4539/config.mk - config file
board/iphase4539/flash.c - flash driver (for AM29LV033C)
board/iphase4539/ppcboot.lds - linker script
board/iphase4539/iphase4539.c - ioport and memory initialization
include/config_IPHASE4539.h - main configuration file
New configuration options:
--------------------------
CONFIG_IPHASE4539
Main board-specific option (should be defined for IPHASE4539).
Acceptance criteria tests:
--------------------------
The following tests have been conducted to validate the port of U-Boot
to IPHASE4539:
1. Operation on serial console:
With SMC1 defined as console in the main configuration file, the U-Boot
output appeared on the serial terminal connected to the 2.5mm stereo jack
connector as follows:
------------------------------------------------------------------------------
=> help
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootd - boot default, i.e., run 'bootcmd'
cmp - memory compare
coninfo - print console devices and informations
cp - memory copy
crc32 - checksum calculation
dcache - enable or disable data cache
echo - echo args to console
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print online help
icache - enable or disable instruction cache
iminfo - print header information for application image
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sleep - delay execution for some time
tftpboot- boot image via network using TFTP protocol
and env variables ipaddr and serverip
version - print monitor version
? - alias for 'help'
=>
------------------------------------------------------------------------------
2. Flash driver operation
The following sequence was performed to test the "flinfo" command:
------------------------------------------------------------------------------
=> flinfo
Bank # 1: AMD AM29LV033C (32 Mbit, uniform sectors)
Size: 4 MB in 64 Sectors
Sector Start Addresses:
FF800000 (RO) FF810000 (RO) FF820000 FF830000 FF840000
FF850000 FF860000 FF870000 FF880000 FF890000
FF8A0000 FF8B0000 FF8C0000 FF8D0000 FF8E0000
FF8F0000 FF900000 FF910000 FF920000 FF930000
FF940000 FF950000 FF960000 FF970000 FF980000
FF990000 FF9A0000 FF9B0000 FF9C0000 FF9D0000
FF9E0000 FF9F0000 FFA00000 FFA10000 FFA20000
FFA30000 FFA40000 FFA50000 FFA60000 FFA70000
FFA80000 FFA90000 FFAA0000 FFAB0000 FFAC0000
FFAD0000 FFAE0000 FFAF0000 FFB00000 (RO) FFB10000 (RO)
FFB20000 (RO) FFB30000 (RO) FFB40000 FFB50000 FFB60000
FFB70000 FFB80000 FFB90000 FFBA0000 FFBB0000
FFBC0000 FFBD0000 FFBE0000 FFBF0000
------------------------------------------------------------------------------
Note: the Hardware Configuration Word (HWC) of the 8260 is on the
first sector of the flash and should not be touched. The U-Boot
environment variables are stored on second sector and U-Boot
starts at the address 0xFFB00000.
The following sequence was performed to test the erase command:
------------------------------------------------------------------------------
=> cp 0 ff880000 10
Copy to Flash... done
=> md ff880000 20
ff880000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
ff880020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
ff880030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> erase ff880000 ff88ffff
Erase Flash from 0xff880000 to 0xff88ffff
.. done
Erased 1 sectors
=> md ff880000
ff880000: ffffffff ffffffff ffffffff ffffffff ................
ff880010: ffffffff ffffffff ffffffff ffffffff ................
ff880020: ffffffff ffffffff ffffffff ffffffff ................
ff880030: ffffffff ffffffff ffffffff ffffffff ................
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> cp 0 ff880000 10
Copy to Flash... done
=> md ff880000 20
ff880000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
ff880020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
ff880030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> erase 1:8
Erase Flash Sectors 8-8 in Bank # 1
.. done
=> md ff880000 20
ff880000: ffffffff ffffffff ffffffff ffffffff ................
ff880010: ffffffff ffffffff ffffffff ffffffff ................
ff880020: ffffffff ffffffff ffffffff ffffffff ................
ff880030: ffffffff ffffffff ffffffff ffffffff ................
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> cp 0 ff880000 10
Copy to Flash... done
=> cp 0 ff890000 10
=> md ff880000 20
ff880000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
ff880020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
ff880030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> md ff890000
ff890000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
ff890010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
ff890020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
ff890030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
ff890040: ffffffff ffffffff ffffffff ffffffff ................
ff890050: ffffffff ffffffff ffffffff ffffffff ................
ff890060: ffffffff ffffffff ffffffff ffffffff ................
ff890070: ffffffff ffffffff ffffffff ffffffff ................
=> erase 1:8-9
Erase Flash Sectors 8-9 in Bank # 1
.... done
=> md ff880000 20
ff880000: ffffffff ffffffff ffffffff ffffffff ................
ff880010: ffffffff ffffffff ffffffff ffffffff ................
ff880020: ffffffff ffffffff ffffffff ffffffff ................
ff880030: ffffffff ffffffff ffffffff ffffffff ................
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=> md ff890000
ff890000: ffffffff ffffffff ffffffff ffffffff ................
ff890010: ffffffff ffffffff ffffffff ffffffff ................
ff890020: ffffffff ffffffff ffffffff ffffffff ................
ff890030: ffffffff ffffffff ffffffff ffffffff ................
ff890040: ffffffff ffffffff ffffffff ffffffff ................
ff890050: ffffffff ffffffff ffffffff ffffffff ................
ff890060: ffffffff ffffffff ffffffff ffffffff ................
ff890070: ffffffff ffffffff ffffffff ffffffff ................
=>
------------------------------------------------------------------------------
The following sequence was performed to test the Flash programming commands:
------------------------------------------------------------------------------
=> erase ff880000 ff88ffff
Erase Flash from 0xff880000 to 0xff88ffff
.. done
Erased 1 sectors
=> cp 0 ff880000 10
Copy to Flash... done
=> md 0 20
00000000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
00000010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
00000020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
00000030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
00000040: 3c83c000 2c040000 40823378 7c0000a6 <...,...@.3x|...
00000050: 60000030 7c1b03a6 3c00c000 600035ec `..0|...<...`.5.
00000060: 7c1a03a6 4c000064 00000000 00000000 |...L..d........
00000070: 00000000 00000000 00000000 00000000 ................
=> md ff880000 20
ff880000: ff000000 60000000 60000000 7c7f1b78 ....`...`...|..x
ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78 |.#x|.+x|.3x|.;x
ff880020: 3b000000 4811e0f5 48003719 480036a5 ;...H...H.7.H.6.
ff880030: 480036f9 48003731 48005c5d 7c7a1b78 H.6.H.71H.\]|z.x
ff880040: ffffffff ffffffff ffffffff ffffffff ................
ff880050: ffffffff ffffffff ffffffff ffffffff ................
ff880060: ffffffff ffffffff ffffffff ffffffff ................
ff880070: ffffffff ffffffff ffffffff ffffffff ................
=>
------------------------------------------------------------------------------
The following sequence was performed to test storage of the environment
variables in Flash:
------------------------------------------------------------------------------
=> setenv foo bar
=> saveenv
Un-Protected 1 sectors
Erasing Flash...
.. done
Erased 1 sectors
Saving Environment to Flash...
Protected 1 sectors
=> reset
...
=> printenv
...
foo=bar
...
Environment size: 339/65532 bytes
=>
------------------------------------------------------------------------------
The following sequence was performed to test image download and run over
Ethernet interface (both interfaces were tested):
------------------------------------------------------------------------------
=> tftpboot 40000 hello_world.bin
ARP broadcast 1
TFTP from server 10.0.0.1; our IP address is 10.0.0.8
Filename 'hello_world.bin'.
Load address: 0x40000
Loading: #############
done
Bytes transferred = 65932 (1018c hex)
=> go 40004
## Starting application at 0x00040004 ...
Hello World
argc = 1
argv[0] = "40004"
argv[1] = "<NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
=>
------------------------------------------------------------------------------
3. Known Problems
None for the moment.
----------------------------------------------------------------------------
U-Boot and Linux for Interphase 4539 T1/E1/J1 PMC Communications Controller
----------------------------------------------------------------------------
U-Boot:
Configure and make U-Boot:
$ cd <path>/u-boot
$ make IPHASE4539_config
$ make dep
$ make
$ cp -p u-boot.bin /tftpboot
Load u-boot.bin into the Flash memory at 0xffb00000.
Linux:
Configure and make Linux:
$ cd <patch>/linux-2.4
$ make IPHASE4539_config
$ make oldconfig
$ make dep
$ make uImage
$ cp -p arch/ppc/mbxboot/uImage /tftpboot
Load uImage via tftp and boot it.
Flash organisation:
The following preliminary layout of the Flash memory
is defined:
0xff800000 ( 0 - 64 kB): Hardware Configuration Word.
0xff810000 ( 64 kB - 128 kB): U-Boot Environment.
0xff820000 ( 128 kB - 3 MB): RAMdisk.
0xffb00000 ( 3 MB - 3328 kB): U-Boot.
0xffb40000 (3328 KB - 4 MB): Linux Kernel.
For further information concerning U-Boot and Linux please consult
the "DENX U-Boot and Linux Guide".
(C) 2002 Wolfgang Grandegger, DENX Software Engineering, wg@denx.de
===================================================================

13
doc/README.IceCube
View File

@ -1,13 +0,0 @@
---------------------------------------------------------------------------
Build target Flash address | BDI "go" command | Reset Vector
---------------------------------------------------------------------------
Lite5200 0xFFF00000 | 0xFFF00100 | 0xFFF00100
Lite5200_LOWBOOT 0xFF000000 | 0xFF000100 | 0x00000100
Lite5200_LOWBOOT08 0xFF800000 | 0xFF800100 | 0x00000100
icecube_5200 0xFFF00000 | 0xFFF00100 | 0xFFF00100
icecube_5200_LOWBOOT 0xFF000000 | 0xFF000100 | 0x00000100
icecube_5200_LOWBOOT08 0xFF800000 | 0xFF800100 | 0x00000100
icecube_5200_DDR 0xFFF00000 | 0xFFF00100 | 0xFFF00100
icecube_5200_DDR_LOWBOOT 0xFF800000 | 0xFF800100 | 0x00000100
icecube_5200_DDR_LOWBOOT08 0xFF800000 | 0xFF800100 | 0x00000100
---------------------------------------------------------------------------

74
doc/README.JFFS2
View File

@ -1,74 +0,0 @@
JFFS2 options and usage.
-----------------------
JFFS2 in U-Boot is a read only implementation of the file system in
Linux with the same name. To use JFFS2 define CFG_CMD_JFFS2.
The module adds three new commands.
fsload - load binary file from a file system image
fsinfo - print information about file systems
ls - list files in a directory
chpart - change active partition
If you boot from a partition which is mounted writable, and you
update your boot environment by replacing single files on that
partition, you should also define CFG_JFFS2_SORT_FRAGMENTS. Scanning
the JFFS2 filesystem takes *much* longer with this feature, though.
Sorting is done while inserting into the fragment list, which is
more or less a bubble sort. That algorithm is known to be O(n^2),
thus you should really consider if you can avoid it!
There is two ways for JFFS2 to find the disk. The default way uses
the flash_info structure to find the start of a JFFS2 disk (called
partition in the code) and you can change where the partition is with
two defines.
CFG_JFFS2_FIRST_BANK
defined the first flash bank to use
CFG_JFFS2_FIRST_SECTOR
defines the first sector to use
The second way is to define CFG_JFFS_CUSTOM_PART and implement the
jffs2_part_info(int part_num) function in your board specific files.
In this mode CFG_JFFS2_FIRST_BANK and CFG_JFFS2_FIRST_SECTOR is not
used.
The input is a partition number starting with 0.
Return a pointer to struct part_info or NULL for error;
Ex jffs2_part_info() for one partition.
---
#if defined CFG_JFFS_CUSTOM_PART
#include <jffs2/jffs2.h>
static struct part_info part;
struct part_info*
jffs2_part_info(int part_num)
{
if(part_num==0){
if(part.usr_priv==(void*)1)
return &part;
memset(&part, 0, sizeof(part));
part.offset=(char*)0xFF800000;
part.size=1024*1024*8;
/* Mark the struct as ready */
part.usr_priv=(void*)1;
return &part;
}
return 0;
}
#endif
---
TODO.
Remove the assumption that JFFS can dereference a pointer
into the disk. The current code do not work with memory holes
or hardware with a sliding window (PCMCIA).

24
doc/README.JFFS2_NAND
View File

@ -1,24 +0,0 @@
JFFS2 NAND support:
To ebable, use the following #define in the board configuration file:
#define CONFIG_JFFS2_NAND 1
Configuration of partitions is similar to how this is done in U-Boot
for JFFS2 on top NOR flash. If a single parition is used, it can be
configured using the following #defines in the configuration file:
#define CONFIG_JFFS2_NAND_DEV 0 /* nand device jffs2 lives on */
#define CONFIG_JFFS2_NAND_OFF 0 /* start of jffs2 partition */
#define CONFIG_JFFS2_NAND_SIZE 2*1024*1024 /* size of jffs2 partition */
If more than a single partition is desired, the user can define a
CFG_JFFS_CUSTOM_PART macro and implement a
struct part_info* jffs2_part_info(int part_num)
function in a board-specific module. An example of such function is
available in common/cmd_jffs2.c
The default configuration for the DAVE board has a single JFFS2
partition of 2 MB size.

68
doc/README.MBX
View File

@ -1,68 +0,0 @@
IMPORTANT NOTE - read before defining CFG_USE_OSCCLK in your board
config file!!!
WARNING: Wrong settings of this parameter have the potential to
damage hardware by running the MBX's CPU at frequencies that exceed
it's rating and/or overdriving the it's SPLL!
Ramblings:
1) Motorola offered 12 different variants of the MBX, 6 823s and 6 860s.
2) Of these 12 variants, only 2 were entry level boards.
3) I believe that the 2 entry level boards were the only ones that
used OSCM clocking. I can't be completely certain of this at this
point.
4) Motorola never offered an MBX that ran faster than 50Mhz.
5) The 10, non-entry level boards, ran at 40Mhz.
6) The EXTCLK input has a minimum clock of 15Mhz for the 823/860.
7) Motorola no longer sells MBXs.
Based on this information, I can surmise that the default power-on
reset clocking was one of the following three options.
Multiplier SPLL Options
------------------------------------
513 OSCM is SPLL input
5 OSCM is SPLL input
1 EXTCLK is SPLL input
The forth option:
5 EXTCLK is SPLL input
is not possible on MBXs. This is because the minimum EXTCLK input
frequency is 15Mhz. 5 * 15Mhz = 75 Mhz. There was no variant that ran
above 50 Mhz.
The board I have borrowed definitely uses a multiplier of 1 for
EXTCLK and runs at 40Mhz. I even went so far as to put a scope on it.
One of the two default OSCM modes are most likely what was used on
the entry level boards to cheapen them by eliminating the external
crystal oscillator.
To add insult to injury, the stupid 860 PLPRCR register retains it's
multiplication factor through hard resets. You can't clear it out
because it is battery backed and once it is set wrong, it stays
wrong. The only way to reset it, so that it takes on it's default
multiplier is to disconnect all power including external, batteries,
as well discharging caps on the board. This precludes the fact that
your 860 may be quite DEAD by this time!
If you don't setup the multiplication factor for boards that use the
OSCM input, they won't run correctly, but at least they won't be
dead.
Addtionally, there is no good way to determine the clock input source
from CPU register data. The only way to deal with this is either hard
code it, determine the correct value with some rather NASTY timing
loops, or try to grok it from external data sources. Motorola
firmware opts for the NASTY timing loops, but needs to configure the
serial ports to do so.
You may have a legitimate need to define CFG_USE_OSCCLK if your
MBX8xx board is using the OSCM clocking mode.
You better know what you are doing here.

24
doc/README.MPC866
View File

@ -1,24 +0,0 @@
The current implementation allows the user to specify the desired CPU
clock value, in MHz, via an environment variable "cpuclk".
Four compile-time constants are used:
CONFIG_8xx_OSCLK - input quartz clock
CFG_8xx_CPUCLK_MIN - minimum allowed CPU clock
CFG_8xx_CPUCLK_MAX - maximum allowed CPU clock
CONFIG_8xx_CPUCLK_DEFAULT - default CPU clock value
If the "cpuclk" environment variable value is within the CPUCLK_MIN /
CPUCLK_MAX limits, the specified value is used. Otherwise, the
default CPU clock value is set.
Please make sure you understand what you are doing, and understand
the restrictions of your hardware (board, processor). For example,
ethernet will stop working for CPU clock frequencies below 25 MHz.
Please note that the new clock-handling code is enabled if
CONFIG_8xx_CPUCLK_DEFAULT is defined. Since this mechanism supports
only MPC866 and newer CPUs, this constant MUST NOT be defined for
MPC823/850/860/862 series. The clock generation algorithm for older
chips is different and has not been implemented yet. If you need it,
your patch is welcome.

72
doc/README.Modem
View File

@ -1,72 +0,0 @@
How to configure modem support in U-Boot :
1. Define modem initialization strings:
---------------------------------------
The modem initialization strings have following format:
mdm_init1=<AT-command>
mdm_init2=<AT-command>
...
Turning off modem verbose responses with ATV0 or ATQ1 is not allowed;
U-Boot analyzes only verbose (not numeric) result codes. Modem local
command echo can be turned off (ATE0).
2. RTS/CTS hardware flow control:
---------------------------------
You may wish to enable RTS/CTS hardware flow control, if the board's
UART driver supports it (see CONFIG_HWFLOW compile-time flag in
config/<board>.h). This is controlled by the 'mdm_flow_control'
environment variable:
'mdm_flow_control=rts/cts' - to enable RTS/CTS flow control.
'mdm_flow_control=none ' - to disable.
The following are the examples using a Rockwell OEM modem
configuration:
SAMSUNG # setenv mdm_init1 ATZ - reset the modem to
the factory defaults.
SAMSUNG # setenv mdm_init2 ATS0=1 - set modem into
answer mode.
SAMSUNG # setenv mdm_flow_control rts/cts - enable serial port
flow control
SAMSUNG # saveenv
The example above initializes modem into answer mode to wait for the
incoming call. RTS/CTS flow control is enabled for the serial port.
(The RTS/CTS flow control is enabled by default on the modem).
SAMSUNG # setenv mdm_init1 ATZ
SAMSUNG # setenv mdm_init2 ATS39=0+IFC=0,0 - disable modem
RTS/CTS flow control
SAMSUNG # setenv mdm_init3 ATDT1643973 - dial out the number
SAMSUNG # setenv mdm_flow_control none
SAMSUNG # saveenv
The example above initializes modem to dial-up connection on the
number 1643973. Flow control is disabled.
Note that flow control must be turned both off or both on for the
board serial port and for the modem.
If the connection was set up successfully, the U-Boot prompt appears
on the terminal console. If not (U-Boot modem was configured for
originating the call and connection was not established) - the board
should be reset for another dial-up try.
Note on the SMDK2400 board:
---------------------------
Since the board serial ports does not have DTR signal wired, modem
should be told to ignore port DTR setting prior to connection to the
SMDK board, and this setting should be stored in modem NVRAM. For the
Rockwell OEM modem this can to be done with the following command:
AT&D0&W

117
doc/README.NetConsole
View File

@ -1,117 +0,0 @@
In U-Boot, we implemented the networked console via the standard
"devices" mechanism, which means that you can switch between the
serial and network input/output devices by adjusting the 'stdin' and
'stdout' environment variables. To switch to the networked console,
set either of these variables to "nc". Input and output can be
switched independently.
We use an environment variable 'ncip' to set the IP address and the
port of the destination. The format is <ip_addr>:<port>. If <port> is
omitted, the value of 6666 is used. If the env var doesn't exist, the
broadcast address and port 6666 are used. If it is set to an IP
address of 0 (or 0.0.0.0) then no messages are sent to the network.
For example, if your server IP is 192.168.1.1, you could use:
=> setenv nc 'setenv stdout nc;setenv stdin nc'
=> setenv ncip 192.168.1.1
=> saveenv
=> run nc
On the host side, please use this script to access the console:
+++++++++++++++++++++++++++++++++++++++++++
#! /bin/bash
[ $# = 1 ] || { echo "Usage: $0 target_ip" >&2 ; exit 1 ; }
TARGET_IP=$1
stty -icanon -echo intr ^T
nc -u -l -p 6666 < /dev/null &
nc -u ${TARGET_IP} 6666
stty icanon echo intr ^C
+++++++++++++++++++++++++++++++++++++++++++
The script expects exactly one argument, which is interpreted as the
target IP address (or host name, assuming DNS is working). The script
can be interrupted by pressing ^T (CTRL-T).
It turns out that 'netcat' cannot be used to listen to broadcast
packets. We developed our own tool 'ncb' (see tools directory) that
listens to broadcast packets on a given port and dumps them to the
standard output. use it as follows:
+++++++++++++++++++++++++++++++++++++++++++
#! /bin/bash
[ $# = 1 ] || { echo "Usage: $0 target_ip" >&2 ; exit 1 ; }
TARGET_IP=$1
stty icanon echo intr ^T
./ncb &
nc -u ${TARGET_IP} 6666
stty icanon echo intr ^C
kill 0
+++++++++++++++++++++++++++++++++++++++++++
Again, this script takes exactly one argument, which is interpreted
as the target IP address (or host name, assuming DNS is working). The
script can be interrupted by pressing ^T (CTRL-T).
The 'ncb' tool can be found in the tools directory; it will not be
built by default so you will ither have to adjust the Makefile or
build it manually.
For Linux, the network-based console needs special configuration.
Minimally, the host IP address needs to be specified. This can be
done either via the kernel command line, or by passing parameters
while loading the netconsole.o module (when used in a loadable module
configuration). Please refer to Documentation/networking/logging.txt
file for the original Ingo Molnar's documentation on how to pass
parameters to the loadable module.
The format of the kernel command line parameter (for the static
configuration) is as follows:
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
where
src-port source for UDP packets
(defaults to 6665)
src-ip source IP to use
(defaults to the interface's address)
dev network interface
(defaults to eth0)
tgt-port port for logging agent
(defaults to 6666)
tgt-ip IP address for logging agent
(this is the required parameter)
tgt-macaddr ethernet MAC address for logging agent
(defaults to broadcast)
Examples:
netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
or
netconsole=@/,@192.168.3.1/
Please note that for the Linux networked console to work, the
ethernet interface has to be up by the time the netconsole driver is
initialized. This means that in case of static kernel configuration,
the respective Ethernet interface has to be brought up using the "IP
Autoconfiguration" kernel feature, which is usually done by defaults
in the ELDK-NFS-based environment.
To browse the Linux network console output, use the 'netcat' tool invoked
as follows:
nc -u -l -p 6666
Note that unlike the U-Boot implementation the Linux netconsole is
unidirectional, i. e. you have console output only in Linux.

28
doc/README.OFT
View File

@ -1,28 +0,0 @@
Open Firmware Flat Tree and usage.
----------------------------------
As part of the ongoing cleanup of the Linux PPC trees, the preferred
way to pass bootloader and board setup information is the open
firmware flat tree.
Please take a look at the following email discussion for some
background.
http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html
http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html
The generated tree is part static and part dynamic.
There is a static part which is compiled in with DTC and a dynamic
part which is programmatically appended.
You'll need a fairly recent DTC tool, which is available by git at
rsync://ozlabs.org/dtc/dtc.git
The xxd binary dumper is needed too which I got from
ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz
Pantelis Antoniou, 13 Oct 2005

24
doc/README.OXC
View File

@ -1,24 +0,0 @@
This document contains different information about the port
of U-Boot for the OXC board designed by Lucent Technologies,
Inc.
1. Showing activity
U-Boot for the OXC board can show its current status using
the Active LED. This feature is configured by the following
options:
CONFIG_SHOW_ACTIVITY
When this option is on, the Active LED is blinking fast
when U-Boot runs in the idle loop (i.e. waits for user
commands from serial console) and blinking slow when it
downloads an image over network. When U-Boot loads an image
over serial line the Active LED does not blink and its state
is random (i.e. either constant on or constant off).
CONFIG_SHOW_BOOT_PROGRESS
When this option is on, U-Boot switches the Active LED
off before booting an image and switches it on if booting
failed due to some reasons.

385
doc/README.PIP405
View File

@ -1,385 +0,0 @@
U-Boot Changes due to PIP405 Port:
===================================
Changed files:
==============
- MAKEALL added PIP405
- makefile added PIP405
- common/Makefile added Floppy disk and SCSI support
- common/board.c added PIP405, SCSI support, get_PCI_freq()
- common/bootm.c added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
- common/cmd_i2c.c added "defined(CONFIG_PIP405)"
- common/cmd_ide.c changed div. functions to work with block device
description
added ATAPI support
- common/command.c added SCSI and Floppy support
- common/console.c replaced // with /* comments
added console settings from environment
- common/devices.c added ISA keyboard init
- common/main.c corrected the read of bootdelay
- cpu/ppc4xx/405gp_pci.c excluded file from PIP405
- cpu/ppc4xx/i2c.c added 16bit read write I2C support
added page write
- cpu/ppc4xx/speed.c added get_PCI_freq
- cpu/ppc4xx/start.S added CONFIG_IDENT_STRING
- disk/Makefile added part_iso for CD support
- disk/part.c changed to work with block device description
added ISO CD support
added dev_print (was ide_print in cmd_ide.c)
- disk/part_dos.c changed to work with block device description
- disk/part_mac.c changed to work with block device description
- include/ata.h added ATAPI commands
- include/cmd_bsp.h added PIP405 commands definitions
- include/cmd_condefs.h added Floppy and SCSI support
- include/cmd_disk.h changed to work with block device description
- include/config_LANTEC.h excluded CFG_CMD_FDC and CFG_CMD_SCSI from
CONFIG_CMD_FULL
- include/config_hymod.h excluded CFG_CMD_FDC and CFG_CMD_SCSI from
CONFIG_CMD_FULL
- include/flash.h added INTEL_ID_28F320C3T 0x88C488C4
- include/i2c.h added "defined(CONFIG_PIP405)"
- include/image.h added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
- include/u-boot.h moved partitions functions definitions to part.h
added "defined(CONFIG_PIP405)"
added get_PCI_freq() definition
- rtc/Makefile added MC146818 RTC support
- tools/mkimage.c added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
Added files:
============
- board/pip405 directory for PIP405
- board/pip405/cmd_pip405.c board specific commands
- board/pip405/config.mk config make
- board/pip405/flash.c flash support
- board/pip405/init.s start-up
- board/pip405/kbd.c keyboard support
- board/pip405/kbd.h keyboard support
- board/pip405/Makefile Makefile
- board/pip405/pci_piix4.h southbridge definitions
- board/pip405/pci_pip405.c PCI support for PIP405
- board/pip405/pci_pip405.h PCI support for PIP405
- board/pip405/pip405.c PIP405 board init
- board/pip405/pip405.h PIP405 board init
- board/pip405/pip405_isa.c ISA support
- board/pip405/pip405_isa.h ISA support
- board/pip405/u-boot.lds Linker description
- board/pip405/u-boot.lds.debugLinker description debug
- board/pip405/sym53c8xx.c SYM53C810A support
- board/pip405/sym53c8xx_defs.h SYM53C810A definitions
- board/pip405/vga_table.h definitions of tables for VGA
- board/pip405/video.c CT69000 support
- board/pip405/video.h CT69000 support
- common/cmd_fdc.c Floppy disk support
- common/cmd_scsi.c SCSI support
- disk/part_iso.c ISO CD ROM support
- disk/part_iso.h ISO CD ROM support
- include/cmd_fdc.h command forFloppy disk support
- include/cmd_scsi.h command for SCSI support
- include/part.h partitions functions definitions
(was part of u-boot.h)
- include/scsi.h SCSI support
- rtc/mc146818.c MC146818 RTC support
New Config Switches:
====================
For detailed description, refer to the corresponding paragraph in the
section "Changes".
New Commands:
-------------
CFG_CMD_SCSI SCSI Support
CFG_CMF_FDC Floppy disk support
IDE additions:
--------------
CONFIG_IDE_RESET_ROUTINE defines that instead of a reset Pin,
the routine ide_set_reset(int idereset) is used.
ATAPI support (experimental)
----------------------------
CONFIG_ATAPI enables ATAPI Support
SCSI support (experimental) only SYM53C8xx supported
----------------------------------------------------
CONFIG_SCSI_SYM53C8XX type of SCSI controller
CFG_SCSI_MAX_LUN 8 number of supported LUNs
CFG_SCSI_MAX_SCSI_ID 7 maximum SCSI ID (0..6)
CFG_SCSI_MAX_DEVICE CFG_SCSI_MAX_SCSI_ID * CFG_SCSI_MAX_LUN
maximum of Target devices (multiple LUN support
for boot)
ISO (CD-Boot) partition support (Experimental)
----------------------------------------------
CONFIG_ISO_PARTITION CD-boot support
RTC
----
CONFIG_RTC_MC146818 MC146818 RTC support
Keyboard:
---------
CONFIG_ISA_KEYBOARD Standard (PC-Style) Keyboard support
Video:
------
CONFIG_VIDEO_CT69000 Enable Chips & Technologies 69000 Video chip
CONFIG_VIDEO must be defined also
External peripheral base address:
---------------------------------
CFG_ISA_IO_BASE_ADDRESS address of all ISA-bus related parts
_must_ be defined for ISA-bus parts
Identify:
---------
CONFIG_IDENT_STRING added to the U_BOOT_VERSION String
I2C stuff:
----------
CFG_EEPROM_PAGE_WRITE_ENABLE enables page write of the I2C EEPROM
CFG_EEPROM_PAGE_WRITE_BITS _must_ be
defined.
Environment / Console:
----------------------
CFG_CONSOLE_IS_IN_ENV if defined, stdin, stdout and stderr used from
the values stored in the evironment.
CFG_CONSOLE_OVERWRITE_ROUTINE if defined, console_overwrite() decides if the
values stored in the environment or the standard
serial in/out put should be assigned to the console.
CFG_CONSOLE_ENV_OVERWRITE if defined, the start-up console switching
are stored in the environment.
PIP405 specific:
----------------
CONFIG_PORT_ADDR address used to read boot configuration
MULTI_PURPOSE_SOCKET_ADDR address of the multi purpose socked
SDRAM_EEPROM_WRITE_ADDRESS addresses of the serial presence detect
SDRAM_EEPROM_READ_ADDRESS EEPROM on the SDRAM module.
Changes:
========
Added Devices:
==============
Floppy support:
---------------
Support of a standard floppy disk controller at address CFG_ISA_IO_BASE_ADDRESS
+ 0x3F0. Enabled with define CFG_CMD_FDC. Reads a unformated floppy disk with a
image header (see: mkimage). No interrupts and no DMA are used for this.
Added files:
- common/cmd_fdc.c
- include/cmd_fdc.h
SCSI support:
-------------
Support for Symbios SYM53C810A chip. Implemented as follows:
- without disconnect
- only asynchrounous
- multiple LUN support (caution, needs a lot of RAM. define CFG_SCSI_MAX_LUN 1 to
save RAM)
- multiple SCSI ID support
- no write support
- analyses the MAC, DOS and ISO pratition similar to the IDE support
- allows booting from SCSI devices similar to the IDE support.
The device numbers are not assigned like they are within the IDE support. The first
device found will get the number 0, the next 1 etc. If all SCSI IDs (0..6) and all
LUNs (8) are enabled, 56 boot devices are possible. This uses a lot of RAM since the
device descriptors are not yet dynamically allocated. 56 boot devices are overkill
anyway. Please refer to the section "Todo" chapter "block device support enhancement".
The SYM53C810A uses 1 Interrupt and must be able of mastering the PCI bus.
Added files:
- common/cmd_scsi.c
- common/board.c
- include/cmd_scsi.h
- include/scsi.h
- board/pip405/sym53c8xx.c
- board/pip405/sym53c8xx_defs.h
ATAPI support (IDE changes):
----------------------------
Added ATAPI support (with CONFIG_ATAPI) in the file cmd_ide.c.
To support a hardreset, when the IDE reset pin is not connected to the
CFG_PC_IDE_RESET pin, the switch CONFIG_IDE_RESET_ROUTINE has been added. When
this switch is enabled the routine void ide_set_reset(int idereset) must be
within the board specific files.
Only read from ATAPI devices are supported.
Found out that the function trim_trail cuts off the last character if the whole
string is filled. Added function cpy_ident instead, which trims also leading
spaces and copies the string in the buffer.
Changed files:
- common/cmd_ide.c
- include/ata.h
ISO partition support:
----------------------
Added CD boot support for El-Torito bootable ISO CDs. The bootfile image must contain
the U-Boot image header. Since CDs do not have "partitions", the boot partition is 0.
The bootcatalog feature has not been tested so far. CD Boot is supported for ATAPI
("diskboot") and SCSI ("scsiboot") devices.
Added files:
- disk/iso_part.c
- disk/iso_part.h
Block device changes:
---------------------
To allow the use of dos_part.c, mac_part.c and iso_part.c, the parameter
block_dev_desc will be used when accessing the functions in these files. The block
device descriptor (block_dev_desc) contains a pointer to the read routine of the
device, which will be used to read blocks from the device.
Renamed function ide_print to dev_print and moved it to the file disk/part.c to use
it for IDE ATAPI and SCSI devices.
Please refer to the section "Todo" chapter "block device support enhancement".
Added files:
- include/part.h
changed files:
- disk/dos_part.c
- disk/dos_part.h
- disk/mac_part.c
- disk/mac_part.h
- disk/part.c
- common/cmd_ide.c
- include/u-boot.h
MC146818 RTC support:
---------------------
Added support for MC146818 RTC with defining CONFIG_RTC_MC146818. The ISA bus IO
base address must be defined with CFG_ISA_IO_BASE_ADDRESS.
Added files:
- rtc/mc146818.c
Standard ISA bus Keyboard support:
----------------------------------
Added support for the standard PC kyeboard controller. For the PIP405 the superIO
controller must be set up previously. The keyboard uses the standard ISA IRQ, so
the ISA PIC must also be set up.
Added files:
- board/pip405/kbd.c
- board/pip405/kbd.h
- board/pip405/pip405_isa.c
- board/pip405/pip405_isa.h
Chips and Technologie 69000 VGA controller support:
---------------------------------------------------
Added support for the CT69000 VGA controller.
Added files:
- board/pip405/video.c
- board/pip405/video.h
- board/pip405/vga_table.h
Changed Items:
==============
Identify:
---------
Added the config variable CONFIG_IDENT_STRING which will be added to the
"U_BOOT_VERSION __TIME__ DATE___ " String, to allows to identify intermidiate
and custom versions.
Changed files:
- cpu/ppc4xx/start.s
Firmware Image:
---------------
Added IH_OS_U_BOOT and IH_TYPE_FIRMWARE to the image definitions to allows the
U-Boot update with prior CRC check.
Changed files:
- include/image.h
- tools/mkimage.c
- common/cmd_bootm.c
Correct PCI Frequency for PPC405:
---------------------------------
Added function (in cpu/ppc4xx/speed.c) to get the PCI frequency for PPC405 CPU.
The PCI Frequency will now be set correct in the board description in common/board.c.
(was set to the busfreq before).
Changed files:
- cpu/ppc4xx/speed.c
- common/board.c
I2C Stuff:
----------
Added defined(CONFIG_PIP405) at several points in common/cmd_i2c.c.
Added 16bit read/write support for I2C (PPC405), and page write to
I2C EEPROM if defined CFG_EEPROM_PAGE_WRITE_ENABLE.
Changed files:
- cpu/ppc4xx/i2c.c
- common/cmd_i2c.c
Environment / Console:
----------------------
Although in README.console described, the U-Boot has not assinged the values
found in the environment to the console. Corrected this behavior, but only if
CFG_CONSOLE_IS_IN_ENV is defined.
If CFG_CONSOLE_OVERWRITE_ROUTINE is defined, console_overwrite() decides if the
values stored in the environment or the standard serial in/output should be
assigned to the console. This is useful if the environment values are not correct.
If CFG_CONSOLE_ENV_OVERWRITE is defined the devices assigned to the console at
start-up time will be written to the environment. This means that if the
environment values are overwritten by the overwrite_console() routine, they will be
stored in the environment.
Changed files:
- common/console.c
Correct bootdelay intepretation:
--------------------------------
Changed bootdelay read from the environment from simple_strtoul (unsigned) to
simple_strtol (signed), to be able to get a bootdelay of -1.
Changed files:
- common/main.c
Todo:
=====
Block device support enhancement:
---------------------------------
Consider to unify the block device handling. Instead of using diskboot for IDE,
scsiboot for SCSI and fdcboot for floppy disks, it would make sense to use only
one command ("devboot" ???) with a parameter of the desired device ("hda1", "sda1",
"fd0" ???) to boot from. The other ide commands can be handled in the same way
("dev hda read.." instead of "ide read.." or "dev sda read.." instead of
"scsi read..."). Todo this, a common way of assign a block device to its name
(first found ide device = hda, second found hdb etc., or hda is device 0 on bus 0,
hdb is device 1 on bus 0 etc.) as well as the names (hdx for ide, sdx for scsi, fx for
floppy ???) must be defined.
Maybe there are better ideas to do this.
Console assingment:
-------------------
Consider to initialize and assign the console stdin, stdout and stderr as soon as
possible to see the boot messages also on an other console than serial.
Todo for PIP405:
================
LCD support for VGA:
--------------------
Add LCD support for the CT69000
Default environment:
--------------------
Consider to write a default environment to the OTP part of the EEPROM and use it
if the normal environment is not valid. Useful for serial# and ethaddr values.
Watchdog:
---------
Implement Watchdog.
Files clean-up:
---------------
Following files needs to be cleaned up:
- cmd_pip405.c
- flash.c
- pci_pip405.c
- pip405.c
- pip405_isa.c
Consider to split up the files in their functions.

736
doc/README.POST
View File

@ -1,736 +0,0 @@
Power-On-Self-Test support in U-Boot
------------------------------------
This project is to support Power-On-Self-Test (POST) in U-Boot.
1. High-level requirements
The key requirements for this project are as follows:
1) The project shall develop a flexible framework for implementing
and running Power-On-Self-Test in U-Boot. This framework shall
possess the following features:
o) Extensibility
The framework shall allow adding/removing/replacing POST tests.
Also, standalone POST tests shall be supported.
o) Configurability
The framework shall allow run-time configuration of the lists
of tests running on normal/power-fail booting.
o) Controllability
The framework shall support manual running of the POST tests.
2) The results of tests shall be saved so that it will be possible to
retrieve them from Linux.
3) The following POST tests shall be developed for MPC823E-based
boards:
o) CPU test
o) Cache test
o) Memory test
o) Ethernet test
o) Serial channels test
o) Watchdog timer test
o) RTC test
o) I2C test
o) SPI test
o) USB test
4) The LWMON board shall be used for reference.
2. Design
This section details the key points of the design for the project.
The whole project can be divided into two independent tasks:
enhancing U-Boot/Linux to provide a common framework for running POST
tests and developing such tests for particular hardware.
2.1. Hardware-independent POST layer
A new optional module will be added to U-Boot, which will run POST
tests and collect their results at boot time. Also, U-Boot will
support running POST tests manually at any time by executing a
special command from the system console.
The list of available POST tests will be configured at U-Boot build
time. The POST layer will allow the developer to add any custom POST
tests. All POST tests will be divided into the following groups:
1) Tests running on power-on booting only
This group will contain those tests that run only once on
power-on reset (e.g. watchdog test)
2) Tests running on normal booting only
This group will contain those tests that do not take much
time and can be run on the regular basis (e.g. CPU test)
3) Tests running in special "slow test mode" only
This group will contain POST tests that consume much time
and cannot be run regularly (e.g. strong memory test, I2C test)
4) Manually executed tests
This group will contain those tests that can be run manually.
If necessary, some tests may belong to several groups simultaneously.
For example, SDRAM test may run in both normal and "slow test" mode.
In normal mode, SDRAM test may perform a fast superficial memory test
only, while running in slow test mode it may perform a full memory
check-up.
Also, all tests will be discriminated by the moment they run at.
Specifically, the following groups will be singled out:
1) Tests running before relocating to RAM
These tests will run immediately after initializing RAM
as to enable modifying it without taking care of its
contents. Basically, this group will contain memory tests
only.
2) Tests running after relocating to RAM
These tests will run immediately before entering the main
loop as to guarantee full hardware initialization.
The POST layer will also distinguish a special group of tests that
may cause system rebooting (e.g. watchdog test). For such tests, the
layer will automatically detect rebooting and will notify the test
about it.
2.1.1. POST layer interfaces
This section details the interfaces between the POST layer and the
rest of U-Boot.
The following flags will be defined:
#define POST_POWERON 0x01 /* test runs on power-on booting */
#define POST_NORMAL 0x02 /* test runs on normal booting */
#define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */
#define POST_POWERTEST 0x08 /* test runs after watchdog reset */
#define POST_ROM 0x100 /* test runs in ROM */
#define POST_RAM 0x200 /* test runs in RAM */
#define POST_MANUAL 0x400 /* test can be executed manually */
#define POST_REBOOT 0x800 /* test may cause rebooting */
#define POST_PREREL 0x1000 /* test runs before relocation */
The POST layer will export the following interface routines:
o) int post_run(bd_t *bd, char *name, int flags);
This routine will run the test (or the group of tests) specified
by the name and flag arguments. More specifically, if the name
argument is not NULL, the test with this name will be performed,
otherwise all tests running in ROM/RAM (depending on the flag
argument) will be executed. This routine will be called at least
twice with name set to NULL, once from board_init_f() and once
from board_init_r(). The flags argument will also specify the
mode the test is executed in (power-on, normal, power-fail,
manual).
o) void post_reloc(ulong offset);
This routine will be called from board_init_r() and will
relocate the POST test table.
o) int post_info(char *name);
This routine will print the list of all POST tests that can be
executed manually if name is NULL, and the description of a
particular test if name is not NULL.
o) int post_log(char *format, ...);
This routine will be called from POST tests to log their
results. Basically, this routine will print the results to
stderr. The format of the arguments and the return value
will be identical to the printf() routine.
Also, the following board-specific routines will be called from the
U-Boot common code:
o) int board_power_mode(void)
This routine will return the mode the system is running in
(POST_POWERON, POST_NORMAL or POST_SHUTDOWN).
o) void board_poweroff(void)
This routine will turn off the power supply of the board. It
will be called on power-fail booting after running all POST
tests.
o) int post_hotkeys_pressed(gd_t *gd)
This routine will scan the keyboard to detect if a magic key
combination has been pressed, or otherwise detect if the
power-on long-running tests shall be executed or not ("normal"
versus "slow" test mode).
The list of available POST tests be kept in the post_tests array
filled at U-Boot build time. The format of entry in this array will
be as follows:
struct post_test {
char *name;
char *cmd;
char *desc;
int flags;
int (*test)(bd_t *bd, int flags);
};
o) name
This field will contain a short name of the test, which will be
used in logs and on listing POST tests (e.g. CPU test).
o) cmd
This field will keep a name for identifying the test on manual
testing (e.g. cpu). For more information, refer to section
"Command line interface".
o) desc
This field will contain a detailed description of the test,
which will be printed on user request. For more information, see
section "Command line interface".
o) flags
This field will contain a combination of the bit flags described
above, which will specify the mode the test is running in
(power-on, normal, power-fail or manual mode), the moment it
should be run at (before or after relocating to RAM), whether it
can cause system rebooting or not.
o) test
This field will contain a pointer to the routine that will
perform the test, which will take 2 arguments. The first
argument will be a pointer to the board info structure, while
the second will be a combination of bit flags specifying the
mode the test is running in (POST_POWERON, POST_NORMAL,
POST_SLOWTEST, POST_MANUAL) and whether the last execution of
the test caused system rebooting (POST_REBOOT). The routine will
return 0 on successful execution of the test, and 1 if the test
failed.
The lists of the POST tests that should be run at power-on/normal/
power-fail booting will be kept in the environment. Namely, the
following environment variables will be used: post_poweron,
powet_normal, post_slowtest.
2.1.2. Test results
The results of tests will be collected by the POST layer. The POST
log will have the following format:
...
--------------------------------------------
START <name>
<test-specific output>
[PASSED|FAILED]
--------------------------------------------
...
Basically, the results of tests will be printed to stderr. This
feature may be enhanced in future to spool the log to a serial line,
save it in non-volatile RAM (NVRAM), transfer it to a dedicated
storage server and etc.
2.1.3. Integration issues
All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
This macro will be defined in the config_<board>.h file for those
boards that need POST. The CONFIG_POST macro will contain the list of
POST tests for the board. The macro will have the format of array
composed of post_test structures:
#define CONFIG_POST \
{
"On-board peripherals test", "board", \
" This test performs full check-up of the " \
"on-board hardware.", \
POST_RAM | POST_SLOWTEST, \
&board_post_test \
}
A new file, post.h, will be created in the include/ directory. This
file will contain common POST declarations and will define a set of
macros that will be reused for defining CONFIG_POST. As an example,
the following macro may be defined:
#define POST_CACHE \
{
"Cache test", "cache", \
" This test verifies the CPU cache operation.", \
POST_RAM | POST_NORMAL, \
&cache_post_test \
}
A new subdirectory will be created in the U-Boot root directory. It
will contain the source code of the POST layer and most of POST
tests. Each POST test in this directory will be placed into a
separate file (it will be needed for building standalone tests). Some
POST tests (mainly those for testing peripheral devices) will be
located in the source files of the drivers for those devices. This
way will be used only if the test subtantially uses the driver.
2.1.4. Standalone tests
The POST framework will allow to develop and run standalone tests. A
user-space library will be developed to provide the POST interface
functions to standalone tests.
2.1.5. Command line interface
A new command, diag, will be added to U-Boot. This command will be
used for listing all available hardware tests, getting detailed
descriptions of them and running these tests.
More specifically, being run without any arguments, this command will
print the list of all available hardware tests:
=> diag
Available hardware tests:
cache - cache test
cpu - CPU test
enet - SCC/FCC ethernet test
Use 'diag [<test1> [<test2>]] ... ' to get more info.
Use 'diag run [<test1> [<test2>]] ... ' to run tests.
=>
If the first argument to the diag command is not 'run', detailed
descriptions of the specified tests will be printed:
=> diag cpu cache
cpu - CPU test
This test verifies the arithmetic logic unit of CPU.
cache - cache test
This test verifies the CPU cache operation.
=>
If the first argument to diag is 'run', the specified tests will be
executed. If no tests are specified, all available tests will be
executed.
It will be prohibited to execute tests running in ROM manually. The
'diag' command will not display such tests and/or run them.
2.1.6. Power failure handling
The Linux kernel will be modified to detect power failures and
automatically reboot the system in such cases. It will be assumed
that the power failure causes a system interrupt.
To perform correct system shutdown, the kernel will register a
handler of the power-fail IRQ on booting. Being called, the handler
will run /sbin/reboot using the call_usermodehelper() routine.
/sbin/reboot will automatically bring the system down in a secure
way. This feature will be configured in/out from the kernel
configuration file.
The POST layer of U-Boot will check whether the system runs in
power-fail mode. If it does, the system will be powered off after
executing all hardware tests.
2.1.7. Hazardous tests
Some tests may cause system rebooting during their execution. For
some tests, this will indicate a failure, while for the Watchdog
test, this means successful operation of the timer.
In order to support such tests, the following scheme will be
implemented. All the tests that may cause system rebooting will have
the POST_REBOOT bit flag set in the flag field of the correspondent
post_test structure. Before starting tests marked with this bit flag,
the POST layer will store an identification number of the test in a
location in IMMR. On booting, the POST layer will check the value of
this variable and if it is set will skip over the tests preceding the
failed one. On second execution of the failed test, the POST_REBOOT
bit flag will be set in the flag argument to the test routine. This
will allow to detect system rebooting on the previous iteration. For
example, the watchdog timer test may have the following
declaration/body:
...
#define POST_WATCHDOG \
{
"Watchdog timer test", "watchdog", \
" This test checks the watchdog timer.", \
POST_RAM | POST_POWERON | POST_REBOOT, \
&watchdog_post_test \
}
...
...
int watchdog_post_test(bd_t *bd, int flags)
{
unsigned long start_time;
if (flags & POST_REBOOT) {
/* Test passed */
return 0;
} else {
/* disable interrupts */
disable_interrupts();
/* 10-second delay */
...
/* if we've reached this, the watchdog timer does not work */
enable_interrupts();
return 1;
}
}
...
2.2. Hardware-specific details
This project will also develop a set of POST tests for MPC8xx- based
systems. This section provides technical details of how it will be
done.
2.2.1. Generic PPC tests
The following generic POST tests will be developed:
o) CPU test
This test will check the arithmetic logic unit (ALU) of CPU. The
test will take several milliseconds and will run on normal
booting.
o) Cache test
This test will verify the CPU cache (L1 cache). The test will
run on normal booting.
o) Memory test
This test will examine RAM and check it for errors. The test
will always run on booting. On normal booting, only a limited
amount of RAM will be checked. On power-fail booting a fool
memory check-up will be performed.
2.2.1.1. CPU test
This test will verify the following ALU instructions:
o) Condition register istructions
This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
cror, crorc, crxor, crnand, crnor, creqv, mcrf.
The mtcrf/mfcr instructions will be tested by loading different
values into the condition register (mtcrf), moving its value to
a general-purpose register (mfcr) and comparing this value with
the expected one. The mcrxr instruction will be tested by
loading a fixed value into the XER register (mtspr), moving XER
value to the condition register (mcrxr), moving it to a
general-purpose register (mfcr) and comparing the value of this
register with the expected one. The rest of instructions will be
tested by loading a fixed value into the condition register
(mtcrf), executing each instruction several times to modify all
4-bit condition fields, moving the value of the conditional
register to a general-purpose register (mfcr) and comparing it
with the expected one.
o) Integer compare instructions
This group will contain: cmp, cmpi, cmpl, cmpli.
To verify these instructions the test will run them with
different combinations of operands, read the condition register
value and compare it with the expected one. More specifically,
the test will contain a pre-built table containing the
description of each test case: the instruction, the values of
the operands, the condition field to save the result in and the
expected result.
o) Arithmetic instructions
This group will contain: add, addc, adde, addme, addze, subf,
subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu,
extsb, extsh.
The test will contain a pre-built table of instructions,
operands, expected results and expected states of the condition
register. For each table entry, the test will cyclically use
different sets of operand registers and result registers. For
example, for instructions that use 3 registers on the first
iteration r0/r1 will be used as operands and r2 for result. On
the second iteration, r1/r2 will be used as operands and r3 as
for result and so on. This will enable to verify all
general-purpose registers.
o) Logic instructions
This group will contain: and, andc, andi, andis, or, orc, ori,
oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw.
The test scheme will be identical to that from the previous
point.
o) Shift instructions
This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
rlwimi
The test scheme will be identical to that from the previous
point.
o) Branch instructions
This group will contain: b, bl, bc.
The first 2 instructions (b, bl) will be verified by jumping to
a fixed address and checking whether control was transfered to
that very point. For the bl instruction the value of the link
register will be checked as well (using mfspr). To verify the bc
instruction various combinations of the BI/BO fields, the CTR
and the condition register values will be checked. The list of
such combinations will be pre-built and linked in U-Boot at
build time.
o) Load/store instructions
This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u).
All operations will be performed on a 16-byte array. The array
will be 4-byte aligned. The base register will point to offset
8. The immediate offset (index register) will range in [-8 ...
+7]. The test cases will be composed so that they will not cause
alignment exceptions. The test will contain a pre-built table
describing all test cases. For store instructions, the table
entry will contain: the instruction opcode, the value of the
index register and the value of the source register. After
executing the instruction, the test will verify the contents of
the array and the value of the base register (it must change for
"store with update" instructions). For load instructions, the
table entry will contain: the instruction opcode, the array
contents, the value of the index register and the expected value
of the destination register. After executing the instruction,
the test will verify the value of the destination register and
the value of the base register (it must change for "load with
update" instructions).
o) Load/store multiple/string instructions
The CPU test will run in RAM in order to allow run-time modification
of the code to reduce the memory footprint.
2.2.1.2 Special-Purpose Registers Tests
TBD.
2.2.1.3. Cache test
To verify the data cache operation the following test scenarios will
be used:
1) Basic test #1
- turn on the data cache
- switch the data cache to write-back or write-through mode
- invalidate the data cache
- write the negative pattern to a cached area
- read the area
The negative pattern must be read at the last step
2) Basic test #2
- turn on the data cache
- switch the data cache to write-back or write-through mode
- invalidate the data cache
- write the zero pattern to a cached area
- turn off the data cache
- write the negative pattern to the area
- turn on the data cache
- read the area
The negative pattern must be read at the last step
3) Write-through mode test
- turn on the data cache
- switch the data cache to write-through mode
- invalidate the data cache
- write the zero pattern to a cached area
- flush the data cache
- write the negative pattern to the area
- turn off the data cache
- read the area
The negative pattern must be read at the last step
4) Write-back mode test
- turn on the data cache
- switch the data cache to write-back mode
- invalidate the data cache
- write the negative pattern to a cached area
- flush the data cache
- write the zero pattern to the area
- invalidate the data cache
- read the area
The negative pattern must be read at the last step
To verify the instruction cache operation the following test
scenarios will be used:
1) Basic test #1
- turn on the instruction cache
- unlock the entire instruction cache
- invalidate the instruction cache
- lock a branch instruction in the instruction cache
- replace the branch instruction with "nop"
- jump to the branch instruction
- check that the branch instruction was executed
2) Basic test #2
- turn on the instruction cache
- unlock the entire instruction cache
- invalidate the instruction cache
- jump to a branch instruction
- check that the branch instruction was executed
- replace the branch instruction with "nop"
- invalidate the instruction cache
- jump to the branch instruction
- check that the "nop" instruction was executed
The CPU test will run in RAM in order to allow run-time modification
of the code.
2.2.1.4. Memory test
The memory test will verify RAM using sequential writes and reads
to/from RAM. Specifically, there will be several test cases that will
use different patterns to verify RAM. Each test case will first fill
a region of RAM with one pattern and then read the region back and
compare its contents with the pattern. The following patterns will be
used:
1) zero pattern (0x00000000)
2) negative pattern (0xffffffff)
3) checkerboard pattern (0x55555555, 0xaaaaaaaa)
4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
5) address pattern (offset, ~offset)
Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
be used to detect adherent bits, i.e. bits whose state may randomly
change if adjacent bits are modified. The last pattern will be used
to detect far-located errors, i.e. situations when writing to one
location modifies an area located far from it. Also, usage of the
last pattern will help to detect memory controller misconfigurations
when RAM represents a cyclically repeated portion of a smaller size.
Being run in normal mode, the test will verify only small 4Kb regions
of RAM around each 1Mb boundary. For example, for 64Mb RAM the
following areas will be verified: 0x00000000-0x00000800,
0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
0x04000000. If the test is run in power-fail mode, it will verify the
whole RAM.
The memory test will run in ROM before relocating U-Boot to RAM in
order to allow RAM modification without saving its contents.
2.2.2. Common tests
This section describes tests that are not based on any hardware
peculiarities and use common U-Boot interfaces only. These tests do
not need any modifications for porting them to another board/CPU.
2.2.2.1. I2C test
For verifying the I2C bus, a full I2C bus scanning will be performed
using the i2c_probe() routine. If any I2C device is found, the test
will be considered as passed, otherwise failed. This particular way
will be used because it provides the most common method of testing.
For example, using the internal loopback mode of the CPM I2C
controller for testing would not work on boards where the software
I2C driver (also known as bit-banged driver) is used.
2.2.2.2. Watchdog timer test
To test the watchdog timer the scheme mentioned above (refer to
section "Hazardous tests") will be used. Namely, this test will be
marked with the POST_REBOOT bit flag. On the first iteration, the
test routine will make a 10-second delay. If the system does not
reboot during this delay, the watchdog timer is not operational and
the test fails. If the system reboots, on the second iteration the
POST_REBOOT bit will be set in the flag argument to the test routine.
The test routine will check this bit and report a success if it is
set.
2.2.2.3. RTC test
The RTC test will use the rtc_get()/rtc_set() routines. The following
features will be verified:
o) Time uniformity
This will be verified by reading RTC in polling within a short
period of time (5-10 seconds).
o) Passing month boundaries
This will be checked by setting RTC to a second before a month
boundary and reading it after its passing the boundary. The test
will be performed for both leap- and nonleap-years.
2.2.3. MPC8xx peripherals tests
This project will develop a set of tests verifying the peripheral
units of MPC8xx processors. Namely, the following controllers of the
MPC8xx communication processor module (CPM) will be tested:
o) Serial Management Controllers (SMC)
o) Serial Communication Controllers (SCC)
2.2.3.1. Ethernet tests (SCC)
The internal (local) loopback mode will be used to test SCC. To do
that the controllers will be configured accordingly and several
packets will be transmitted. These tests may be enhanced in future to
use external loopback for testing. That will need appropriate
reconfiguration of the physical interface chip.
The test routines for the SCC ethernet tests will be located in
cpu/mpc8xx/scc.c.
2.2.3.2. UART tests (SMC/SCC)
To perform these tests the internal (local) loopback mode will be
used. The SMC/SCC controllers will be configured to connect the
transmitter output to the receiver input. After that, several bytes
will be transmitted. These tests may be enhanced to make to perform
"external" loopback test using a loopback cable. In this case, the
test will be executed manually.
The test routine for the SMC/SCC UART tests will be located in
cpu/mpc8xx/serial.c.
2.2.3.3. USB test
TBD
2.2.3.4. SPI test
TBD

48
doc/README.PXA_CF
View File

@ -1,48 +0,0 @@
These are brief instructions on how to add support for CF adapters to
custom designed PXA boards. You need to set the parameters in the
config file. This should work for most implementations especially if you
follow the connections of the standard lubbock. Anyway just the block
marked memory configuration should be touched since the other parameters
are imposed by the PXA architecture.
#define CONFIG_PXA_PCMCIA 1
#define CONFIG_PXA_IDE 1
#define CONFIG_PCMCIA_SLOT_A 1
/* just to keep build system happy */
#define CFG_PCMCIA_MEM_ADDR 0x28000000
#define CFG_PCMCIA_MEM_SIZE 0x10000000
#define CFG_MECR_VAL 0x00000000
#define CFG_MCMEM0_VAL 0x00004204
#define CFG_MCMEM1_VAL 0x00000000
#define CFG_MCATT0_VAL 0x00010504
#define CFG_MCATT1_VAL 0x00000000
#define CFG_MCIO0_VAL 0x00008407
#define CFG_MCIO1_VAL 0x00000000
/* memory configuration */
#define CFG_IDE_MAXBUS 1
/* max. 1 IDE bus */
#define CFG_IDE_MAXDEVICE 1
/* max. 1 drive per IDE bus */
#define CFG_ATA_IDE0_OFFSET 0x0000
#define CFG_ATA_BASE_ADDR 0x20000000
/* Offset for data I/O */
#define CFG_ATA_DATA_OFFSET 0x1f0
/* Offset for normal register accesses */
#define CFG_ATA_REG_OFFSET 0x1f0
/* Offset for alternate registers */
#define CFG_ATA_ALT_OFFSET 0x3f0
Another important point is that maybe you have to power the pcmcia
subsystem. This is very board specific, for an example on how to
do it please search for CONFIG_EXADRON1 in cmd_pcmcia.c

163
doc/README.PlanetCore
View File

@ -1,163 +0,0 @@
After several heart-struck failure, I got one workable way to program
each other in FLASH between PlanetCore and U-Boot.
Hardware Platform : RPXlite DW(EP 823 H1 DW)
1. From U-Boot to PlanetCore
Utilities : PlanetCore Boot Loader - PCL200.mot
[root@sam tftpboot]# ppc_8xx-objcopy -O ppcboot
PCL200.mot pcl200.bin
[Target Operation]
u-boot>t 100000 pcl200.bin
u-boot>go 0x100000
## Starting application at 0x00100000 ...
MPC8xx PlanetCore Flash Burner v2.00
Copyright 2001 Embedded Planet. All rights reserved.
Construct Flash Device.....done.
Program MPC8xx PlanetCore Boot Loader v2.00
Built Sep 19, 2001 at 14:34:42
Image located from FC000000 to FC01B5D1.
(Skipping an image, only loading low boot image)
Low boot board detected, skipping high boot image.
Erasing, programming and verifying will start in 20
seconds
Press P to start immediately or ESC to cancel
Press Space or Enter for more options.
..............
Erasing
Programming
FLASH programmed successfully!
Press R to induce a hard reset
MPC8xx PlanetCore Boot Loader v2.00
Copyright 2001 Embedded Planet. All rights reserved.
DRAM available size = 64 MB
wvCV
DRAM OK
>
2. From PlanetCore to U-Boot
Utilities : PlanetCore FLASH Burner - PCB200.mot
Use Flash Burner to finish the work:
First, TFTP the U-Boot image file to RAM; For example,
RPXlite_DW.bin to 0x400000
Second, TFTP FLASH Burner to RAM; For example,
0x100000
Third, run the FLASH Burner and Program the U-Boot
image into the correct location in FLASH.
[Target Operation]
MPC8xx PlanetCore Boot Loader v2.00
Copyright 2001 Embedded Planet. All rights reserved.
DRAM available size = 64 MB
wvCV
DRAM OK
>t
Load using tftp via Ethernet
Enter server IP address <172.16.115.6> :
Enter server filename <PCL200.mot> : RPXlite_DW.bin
Enter (B)inary or (S)record input mode <S> : B
Enter address offset : <00400000 hex> :
Total bytes = 120096 in 232184 uSecs
Loaded addresses 00400000 through 0041D51F.
Start address = 00400000
>t
Load using tftp via Ethernet
Enter server IP address <172.16.115.6> :
Enter server filename <RPXlite_DW.bin> : PCB200.mot
Enter (B)inary or (S)record input mode <B> : S
Enter address offset : <00000000 hex> :
.512.1024..2048....4096.....
Total bytes = 326280 in 2570249 uSecs
Loaded addresses 00100000 through 0011BB51.
Start address = 00100000
>go
[Go 00100000]
MPC8xx PlanetCore Flash Burner v2.00
Copyright 2001 Embedded Planet. All rights reserved.
Construct Flash Device.....done.
Bad start address
Start = 0xFFFFFFFF, target = 0xFFFFFFFF, length =
0xFFFFFFFF
Forcing Menu Interface
h[elp] Show commands.
c[ode] Show information on code to be loaded.
di[splay] Display all flash sections.
du[mp] Dump memory. d ? for more info.
e[rase] Erase flash sections.
f[ill] Fill flash sections.
im[age] Toggle load high, low, or both flash
images.
in[fo] Show flash information.
ma[p] Show memory map.
mo[dify] Modify memory. m ? for more info.
p[rogram] Erase, program, and verify now.
reset Restart the loader.
s[how] Show flash sections to erase and program.
t[est] Test flash sections.
q[uit] Quit without programming.
#program 400000 ff000000 1D51F
doProgram( 400000 ff000000 1D51F )
Start = 0x00400000, target = 0xFF000000, length =
0x0001D51F
Erasing sector 0xFF000000, length 0x008000.
Erasing sector 0xFF008000, length 0x008000.
Erasing sector 0xFF010000, length 0x008000.
Erasing sector 0xFF018000, length 0x008000.
Programming FF000000 through FF01D51E
FLASH programmed successfully!
Press R to induce a hard reset
Forcing Hard Reset by MachineCheck and
ResetOnCheckstop...
U-Boot 1.1.2 (Aug 29 2004 - 15:11:27)
CPU: PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
D-Cache
Board: RPXlite_DW
DRAM: 64 MB
FLASH: 16 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: SCC ETHERNET
u-boot>
-------------------------------------------------
Well, sometimes network function of PlanetCore couldn't work when
switching from U-Boot to PlanetCore. For example, you couldn't
download a file from HOST PC via TFTP. Don't worry, just restart your
HOST PC and everything would work as smooth as clockwork. I don't
know the reason WHY:-)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Merry Christmas and Happy New Year!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=====
Best regards,
Sam

84
doc/README.Purple
View File

@ -1,84 +0,0 @@
Installation Instructions:
--------------------------
1. Put the s2 switch into the following position:
Off On
------
|x |
| x|
|x |
| X|
------
Put the s3 switch into the following position:
Off On
------
| x |
| x |
| x|
| x|
------
Put the s4 switch into the following position:
Off On
------
|x |
|x |
|x |
|x |
|x |
| x|
| x|
|x |
------
2. Connect to the serial console and to the BDI. Power on. On the
serial line, you should see:
PURPLE@1.2>
3. Type '8'. No echo will be displayed. In response, you should get:
7A(pass)
4. From BDI, enter command:
mmw 0xb800d860 0x0042c7ff
5. Then, from BDI:
erase 0xB0000000
erase 0xB0008000
erase 0xB000C000
erase 0xB0010000
erase 0xB0020000
prog 0xB0000000 <u-boot.bin> bin
6. Power off. Restore the original S2 switch position:
Off On
------
| x|
| x|
|x |
| X|
------
Power on. U-Boot should come up.
Implementation Notes:
---------------------
Due to the RAM/flash bus arbitration problem the suggested workaround
had to be implemented. It works okay. On the downside is that you
can't really check whether 'erase' is complete by polling flash as it
is usually done. Instead, the flash driver simply waits for a given
time and assumes that erase then has passed. This behaviour is
identical to what the VxWorks driver does; also, the same timeout (6
seconds) was chosen. Note that this timeout applies for each erase
operation, i. e. per erased sector.

19
doc/README.RPXClassic
View File

@ -1,19 +0,0 @@
# Porting U-Boot onto RPXClassic LF_BW31 board
# Written by Pierre AUBERT
# E-Mail p.aubert@staubli.com
# Stäubli Faverges - <www.staubli.com>
#
# Sept. 20 2001
#
# Cross compile: Montavista Hardhat ported on HP-UX 10.20
#
Flash memories : AM29DL323B (2 banks flash memories) 16 Mb from 0xff000000
DRAM : 16 Mb from 0
NVRAM : 512 kb from 0xfa000000
- environment is stored in NVRAM
- Mac address is read from EEPROM
- ethernet on SCC1 or fast ethernet on FEC are running (depending on the
configuration flag CONFIG_FEC_ENET)

877
doc/README.RPXlite
View File

@ -1,877 +0,0 @@
# Porting U-Boot onto RPXlite board
# Written by Yoo. Jonghoon
# E-Mail : yooth@ipone.co.kr
# IP ONE Inc.
# Since 2001. 1. 29
# Shell : bash
# Cross-compile tools : Montavista Hardhat
# Debugging tools : Windriver VisionProbe (PowerPC BDM)
# ppcboot ver. : ppcboot-0.8.1
###############################################################
# 1. Hardware setting
###############################################################
1.1. Board, BDM settings
Install board, BDM, connect each other
1.2. Save Register value
Boot with board-on monitor program and save the
register values with BDM.
1.3. Configure flash programmer
Check flash memory area in the memory map.
0xFFC00000 - 0xFFFFFFFF
Boot monitor program is at
0xFFF00000
You can program on-board flash memory with VisionClick
flash programmer. Set the target flash device as:
29DL800B
(?) The flash memory device in the board *is* 29LV800B,
but I cannot program it with '29LV800B' option.
(in VisionClick flash programming tools)
I don't know why...
1.4. Save boot monitor program *IMPORTANT*
Upload boot monitor program from board to file.
boot monitor program starts at 0xFFF00000
1.5. Test flash memory programming
Try to erase boot program in the flash memory,
and re-write them.
*WARNING* YOU MUST SAVE BOOT PROGRAM TO FILE
BEFORE ERASING FLASH
###############################################################
# 2. U-Boot setting
###############################################################
2.1. Download U-Boot tarball at
ftp://ftp.denx.de
(The latest version is ppcboot-0.8.1.tar.bz2)
To extract the archive use the following syntax :
> bzip2 -cd ppcboot-0.8.1.tar.bz2 | tar xf -
2.2. Add the following lines in '.profile'
export PATH=$PATH:/opt/hardhat/devkit/ppc/8xx/bin
2.3. Make board specific config, for example:
> cd ppcboot-0.8.1
> make TQM860L_config
Now we can build ppcboot bin files.
After make all, you must see these files in your
ppcboot root directory.
ppcboot
ppcboot.bin
ppcboot.srec
ppcboot.map
2.4. Make your own board directory into the
ppcboot-0.8.1/board
and make your board-specific files here.
For exmanple, tqm8xx files are composed of
.depend : Nothing
Makefile : To make config file
config.mk : Sets base address
flash.c : Flash memory control files
ppcboot.lds : linker(ld) script? (I don't know this yet)
tqm8xx.c : DRAM control and board check routines
And, add your board config lines in the
ppcboot-0.8.1/Makefile
Finally, add config_(your board).h file in the
ppcboot-0.8.1/include/
I've made board/rpxlite directory, and just copied
tqm8xx settings for now.
Rebuild ppcboot for rpxlite board:
> make rpxlite_config
> make
###############################################################
# 3. U-Boot porting
###############################################################
3.1. My RPXlite files are based on tqm8xx board files.
> cd board
> cp -r tqm8xx RPXLITE
> cd RPXLITE
> mv tqm8xx.c RPXLITE.c
> cd ../../include
> cp config_tqm8xx.h config_RPXLITE.h
3.2. Modified files are:
board/RPXLITE/RPXLITE.c /* DRAM-related routines */
board/RPXLITE/flash.c /* flash-related routines */
board/RPXLITE/config.mk /* set text base address */
cpu/mpc8xx/serial.c /* board specific register setting */
include/config_RPXLITE.h /* board specific registers */
See 'reg_config.txt' for register values in detail.
###############################################################
# 4. Running Linux
###############################################################
###############################################################
# Misc Information
###############################################################
mem_config.txt:
===============
Flash memory device : AM29LV800BB (1Mx8Bit) x 4 device
manufacturer id : 01 (AMD)
device id : 5B (AM29LV800B)
size : 4Mbyte
sector # : 19
Sector information :
number start addr. size
00 FFC0_0000 64
01 FFC1_0000 32
02 FFC1_8000 32
03 FFC2_0000 128
04 FFC4_0000 256
05 FFC8_0000 256
06 FFCC_0000 256
07 FFD0_0000 256
08 FFD4_0000 256
09 FFD8_0000 256
10 FFDC_0000 256
11 FFE0_0000 256
12 FFE4_0000 256
13 FFE8_0000 256
14 FFEC_0000 256
15 FFF0_0000 256
16 FFF4_0000 256
17 FFF8_0000 256
18 FFFC_0000 256
reg_config.txt:
===============
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* SIU (System Interface Unit) */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/*### IMMR */
/*### Internal Memory Map Register */
/*### Chap. 11.4.1 */
ISB = 0xFA20 /* Set the Immap base = 0xFA20 0000 */
PARTNUM = 0x21
MASKNUM = 0x00
=> 0xFA20 2100
---------------------------------------------------------------------
/*### SIUMCR */
/*### SIU Module Configuration Register */
/*### Chap. 11.4.2 */
/*### Offset : 0x0000 0000 */
EARB = 0
EARP = 0
DSHW = 0
DBGC = 0
DBPC = 0
FRC = 0
DLK = 0
OPAR = 0
PNCS = 0
DPC = 0
MPRE = 0
MLRC = 10 /* ~KR/~RETRY/~IRQ4/SPKROUT functions as ~KR/~TRTRY */
AEME = 0
SEME = 0
BSC = 0
GB5E = 0
B2DD = 0
B3DD = 0
=> 0x0000 0800
---------------------------------------------------------------------
/*### SYPCR */
/*### System Protection Control Register */
/*### Chap. 11.4.3 */
/*### Offset : 0x0000 0004 */
SWTC = 0xFFFF /* SW watchdog timer count = 0xFFFF */
BMT = 0x06 /* BUS monitoring timing */
BME = 1 /* BUS monitor enable */
SWF = 1
SWE = 0 /* SW watchdog disable */
SWRI = 0
SWP = 1
=> 0xFFFF 0689
---------------------------------------------------------------------
/*### TESR */
/*### Transfer Error Status Register */
/*### Chap. 11.4.4 */
/*### Offset : 0x0000 0020 */
IEXT = 0
ITMT = 0
IPB = 0000
DEXT = 0
DTMT = 0
DPB = 0000
=> 0x0000 0000
---------------------------------------------------------------------
/*### SIPEND */
/*### SIU Interrupt Pending Register */
/*### Chap. 11.5.4.1 */
/*### Offset : 0x0000 0010 */
IRQ0~IRQ7 = 0
LVL0~LVL7 = 0
=> 0x0000 0000
---------------------------------------------------------------------
/*### SIMASK */
/*### SIU Interrupt Mask Register */
/*### Chap. 11.5.4.2 */
/*### Offset : 0x0000 0014 */
IRM0~IRM7 = 0 /* Mask all interrupts */
LVL0~LVL7 = 0
=> 0x0000 0000
---------------------------------------------------------------------
/*### SIEL */
/*### SIU Interrupt Edge/Level Register */
/*### Chap. 11.5.4.3 */
/*### Offset : 0x0000 0018 */
ED0~ED7 = 0 /* Low level triggered */
WMn0~WMn7 = 0 /* Not allowed to exit from low-power mode */
=> 0x0000 0000
---------------------------------------------------------------------
/*### SIVEC */
/*### SIU Interrupt Vector Register */
/*### Chap. 11.5.4.4 */
/*### Offset : 0x0000 001C */
INTC = 3C /* The lowest interrupt is pending..(?) */
=> 0x3C00 0000
---------------------------------------------------------------------
/*### SWSR */
/*### Software Service Register */
/*### Chap. 11.7.1 */
/*### Offset : 0x0000 001E */
SEQ = 0
=> 0x0000
---------------------------------------------------------------------
/*### SDCR */
/*### SDMA Configuration Register */
/*### Chap. 20.2.1 */
/*### Offset : 0x0000 0032 */
FRZ = 0
RAID = 01 /* Priority level 5 (BR5) (normal operation) */
=> 0x0000 0001
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* UPMA (User Programmable Machine A) */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/*### Chap. 16.6.4.1 */
/*### Offset = 0x0000 017c */
T0 = CFFF CC24 /* Single Read */
T1 = 0FFF CC04
T2 = 0CAF CC04
T3 = 03AF CC08
T4 = 3FBF CC27 /* last */
T5 = FFFF CC25
T6 = FFFF CC25
T7 = FFFF CC25
T8 = CFFF CC24 /* Burst Read */
T9 = 0FFF CC04
T10 = 0CAF CC84
T11 = 03AF CC88
T12 = 3FBF CC27 /* last */
T13 = FFFF CC25
T14 = FFFF CC25
T15 = FFFF CC25
T16 = FFFF CC25
T17 = FFFF CC25
T18 = FFFF CC25
T19 = FFFF CC25
T20 = FFFF CC25
T21 = FFFF CC25
T22 = FFFF CC25
T23 = FFFF CC25
T24 = CFFF CC24 /* Single Write */
T25 = 0FFF CC04
T26 = 0CFF CC04
T27 = 03FF CC00
T28 = 3FFF CC27 /* last */
T29 = FFFF CC25
T30 = FFFF CC25
T31 = FFFF CC25
T32 = CFFF CC24 /* Burst Write */
T33 = 0FFF CC04
T34 = 0CFF CC80
T35 = 03FF CC8C
T36 = 0CFF CC00
T37 = 33FF CC27 /* last */
T38 = FFFF CC25
T39 = FFFF CC25
T40 = FFFF CC25
T41 = FFFF CC25
T42 = FFFF CC25
T43 = FFFF CC25
T44 = FFFF CC25
T45 = FFFF CC25
T46 = FFFF CC25
T47 = FFFF CC25
T48 = C0FF CC24 /* Refresh */
T49 = 03FF CC24
T50 = 0FFF CC24
T51 = 0FFF CC24
T52 = 3FFF CC27 /* last */
T53 = FFFF CC25
T54 = FFFF CC25
T55 = FFFF CC25
T56 = FFFF CC25
T57 = FFFF CC25
T58 = FFFF CC25
T59 = FFFF CC25
T60 = FFFF CC25 /* Exception */
T61 = FFFF CC25
T62 = FFFF CC25
T63 = FFFF CC25
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* UPMB */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
---------------------------------------------------------------------
/*### Chap. 16.6.4.1 */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* MEMC */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
---------------------------------------------------------------------
/*### BR0 & OR0 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR0(0x0000 0100) & OR0(0x0000 0104) */
/*### Flash memory */
BA = 1111 1110 0000 0000 0 /* Base addr = 0xFE00 0000 */
AT = 000
PS = 00
PARE = 0
WP = 0
MS = 0 /* GPCM */
V = 1 /* Valid */
=> 0xFE00 0001
AM = 1111 1110 0000 0000 0 /* 32MBytes */
ATM = 000
CSNT/SAM = 0
ACS/G5LA,G5LS = 00
BIH = 1 /* Burst inhibited */
SCY = 0100 /* cycle length = 4 */
SETA = 0
TRLX = 0
EHTR = 0
=> 0xFE00 0140
/*### BR1 & OR1 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR1(0x0000 0108) & OR1(0x0000 010C) */
/*### SDRAM */
BA = 0000 0000 0000 0000 0 /* Base addr = 0x0000 0000 */
AT = 000
PS = 00
PARE = 0
WP = 0
MS = 1 /* UPMA */
V = 1 /* Valid */
=> 0x0000 0081
AM = 1111 1110 0000 0000 /* 32MBytes */
ATM = 000
CSNT/SAM = 1
ACS/G5LA,G5LS = 11
BIH = 0
SCY = 0000 /* cycle length = 0 */
SETA = 0
TRLX = 0
EHTR = 0
=> 0xFE00 0E00
/*### BR2 & OR2 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR2(0x0000 0110) & OR2(0x0000 0114) */
BR2 & OR2 = 0x0000 0000 /* Not used */
/*### BR3 & OR3 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR3(0x0000 0118) & OR3(0x0000 011C) */
/*### BCSR */
BA = 1111 1010 0100 0000 0 /* Base addr = 0xFA40 0000 */
AT = 000
PS = 00
PARE = 0
WP = 0
MS = 0 /* GPCM */
V = 1 /* Valid */
=> 0xFA40 0001
AM = 1111 1111 0111 1111 1 /* (?) */
ATM = 000
CSNT/SAM = 1
ACS/G5LA,G5LS = 00
BIH = 1 /* Burst inhibited */
SCY = 0001 /* cycle length = 1 */
SETA = 0
TRLX = 0
=> 0xFF7F 8910
/*### BR4 & OR4 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR4(0x0000 0120) & OR4(0x0000 0124) */
/*### NVRAM & SRAM */
BA = 1111 1010 0000 0000 0 /* Base addr = 0xFA00 0000 */
AT = 000
PS = 01
PARE = 0
WP = 0
MS = 0 /* GPCM */
V = 1 /* Valid */
=> 0xFA00 0401
AM = 1111 1111 1111 1000 0 /* 8MByte */
ATM = 000
CSNT/SAM = 1
ACS/G5LA,G5LS = 00
BIH = 1 /* Burst inhibited */
SCY = 0111 /* cycle length = 7 */
SETA = 0
TRLX = 0
=> 0xFFF8 0970
/*### BR5 & OR5 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR2(0x0000 0128) & OR2(0x0000 012C) */
BR5 & OR5 = 0x0000 0000 /* Not used */
/*### BR6 & OR6 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR2(0x0000 0130) & OR2(0x0000 0134) */
BR6 & OR6 = 0x0000 0000 /* Not used */
/*### BR7 & OR7 */
/*### Base Registers & Option Registers */
/*### Chap. 16.4.1 & 16.4.2 */
/*### Offset : BR7(0x0000 0138) & OR7(0x0000 013C) */
BR7 & OR7 = 0x0000 0000 /* Not used */
/*### MAR */
/*### Memory Address Register */
/*### Chap. 16.4.7 */
/*### Offset : 0x0000 0164 */
MA = External memory address
/*### MCR */
/*### Memory Command Register */
/*### Chap. 16.4.5 */
/*### Offset : 0x0000 0168 */
OP = xx /* Command op code */
UM = 1 /* Select UPMA */
MB = 001 /* Select CS1 */
MCLF = xxxx /* Loop times */
MAD = xx xxxx /* Memory array index */
/*### MAMR */
/*### Machine A Mode Register */
/*### Chap. 16.4.4 */
/*### Offset : 0x0000 0170 */
PTA = 0101 1000
PTAE = 1 /* Periodic timer A enabled */
AMA = 010
DSA = 00
G0CLA = 000
GPLA4DIS = 1
RLFA = 0100
WLFA = 0011
TLFA = 0000
=> 0x58A0 1430
/*### MBMR */
/*### Machine B Mode Register */
/*### Chap. 16.4.4 */
/*### Offset : 0x0000 0174 */
PTA = 0100 1110
PTAE = 0 /* Periodic timer B disabled */
AMA = 000
DSA = 00
G0CLA = 000
GPLA4DIS = 1
RLFA = 0000
WLFA = 0000
TLFA = 0000
=> 0x4E00 1000
/*### MSTAT */
/*### Memory Status Register */
/*### Chap. 16.4.3 */
/*### Offset : 0x0000 0178 */
PER0~PER7 = Parity error
WPER = Write protection error
=> 0x0000
/*### MPTPR */
/*### Memory Periodic Timer Prescaler Register */
/*### Chap. 16.4.8 */
/*### Offset : 0x0000 017A */
PTP = 0000 1000 /* Divide by 8 */
=> 0x0800
/*### MDR */
/*### Memory Data Register */
/*### Chap. 16.4.6 */
/*### Offset : 0x0000 017C */
MD = Memory data contains the RAM array word
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* TIMERS */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
---------------------------------------------------------------------
/*### TBREFx */
/*### Timebase Reference Registers */
/*### Chap. 11.9.2 */
/*### Offset : TBREFF0(0x0000 0204)/TBREFF1(0x0000 0208) */
/*### (Locked) */
TBREFF0 = 0xFFFF FFFF
TBREFF1 = 0xFFFF FFFF
---------------------------------------------------------------------
/*### TBSCR */
/*### Timebase Status and Control Registers */
/*### Chap. 11.9.3 */
/*### Offset : 0x0000 0200 */
/*### (Locked) */
TBIRQ = 00000000
REF0 = 0
REF1 = 0
REFE0 = 0 /* Reference interrupt disable */
REFE1 = 0
TBF = 1
TBE = 1 /* Timebase enable */
=> 0x0003
---------------------------------------------------------------------
/*### RTCSC */
/*### Real-Time Clock Status and Control Registers */
/*### Chap. 11.10.1 */
/*### Offset : 0x0000 0220 */
/*### (Locked) */
RTCIRQ = 00000000
SEC = 1
ALR = 0
38K = 0 /* PITRTCLK is driven by 32.768KHz */
SIE = 0
ALE = 0
RTF = 0
RTE = 1 /* Real-Time clock enabled */
=> 0x0081
---------------------------------------------------------------------
/*### RTC */
/*### Real-Time Clock Registers */
/*### Chap. 11.10.2 */
/*### Offset : 0x0000 0224 */
/*### (Locked) */
RTC = Real time clock measured in second
---------------------------------------------------------------------
/*### RTCAL */
/*### Real-Time Clock Alarm Registers */
/*### Chap. 11.10.3 */
/*### Offset : 0x0000 022C */
/*### (Locked) */
ALARM = 0xFFFF FFFF
---------------------------------------------------------------------
/*### RTSEC */
/*### Real-Time Clock Alarm Second Registers */
/*### Chap. 11.10.4 */
/*### Offset : 0x0000 0228 */
/*### (Locked) */
COUNTER = Counter bits(fraction of a second)
---------------------------------------------------------------------
/*### PISCR */
/*### Periodic Interrupt Status and Control Register */
/*### Chap. 11.11.1 */
/*### Offset : 0x0000 0240 */
/*### (Locked) */
PIRQ = 0
PS = 0 /* Write 1 to clear */
PIE = 0
PITF = 1
PTE = 0 /* PIT disabled */
---------------------------------------------------------------------
/*### PITC */
/*### PIT Count Register */
/*### Chap. 11.11.2 */
/*### Offset : 0x0000 0244 */
/*### (Locked) */
PITC = PIT count
---------------------------------------------------------------------
/*### PITR */
/*### PIT Register */
/*### Chap. 11.11.3 */
/*### Offset : 0x0000 0248 */
/*### (Locked) */
PIT = PIT count /* Read only */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* CLOCKS */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
---------------------------------------------------------------------
---------------------------------------------------------------------
/*### SCCR */
/*### System Clock and Reset Control Register */
/*### Chap. 15.6.1 */
/*### Offset : 0x0000 0280 */
/*### (Locked) */
COM = 11 /* Clock output disabled */
TBS = 1 /* Timebase frequency source is GCLK2 divided by 16 */
RTDIV = 0 /* The clock is divided by 4 */
RTSEL = 0 /* OSCM(Crystal oscillator) is selected */
CRQEN = 0
PRQEN = 0
EBDF = 00 /* CLKOUT is GCLK2 divided by 1 */
DFSYNC = 00 /* Divided by 1 (normal operation) */
DFBRG = 00 /* Divided by 1 (normal operation) */
DFNL = 000
DFNH = 000
=> 0x6200 0000
---------------------------------------------------------------------
/*### PLPRCR */
/*### PLL, Low-Power, and Reset Control Register */
/*### Chap. 15.6.2 */
/*### Offset : 0x0000 0284 */
/*### (Locked) */
MF = 0x005 /* 48MHz (?) ( = 8MHz * (MF+1) ) */
SPLSS = 0
TEXPS = 0
TMIST = 0
CSRC = 0 /* The general system clock is generated by the DFNH field */
LPM = 00 /* Normal high/normal low mode */
CSR = 0
LOLRE = 0
FIOPD = 0
=> 0x0050 0000
---------------------------------------------------------------------
/*### RSR */
/*### Reset Status Register */
/*### Chap. 12.2 */
/*### Offset : 0x0000 0288 */
/*### (Locked) */
EHRS = External hard reset
ESRS = External soft reset
LLRS = Loss-of-lock reset
SWRS = Software watchdog reset
CSRS = Check stop reset
DBHRS = Debug port hard reset
DBSRS = Debug port soft reset
JTRS = JTAG reset
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
/* DMA */
/* */
/*------------------------------------------------------------------- */
/*------------------------------------------------------------------- */
---------------------------------------------------------------------
/*### SDSR */
/*### SDMA Status Register */
/*### Chap. 20.2.2 */
/*### Offset : 0x0000 0908 */
SBER = 0 /* SDMA channel bus error */
DSP2 = 0 /* DSP chain2 (Tx) interrupt */
DSP1 = 0 /* DSP chain1 (Rx) interrupt */
=> 0x00
/*### SDMR */
/*### SDMA Mask Register */
/*### Chap. 20.2.3 */
/*### Offset : 0x0000 090C */
SBER = 0
DSP2 = 0
DSP1 = 0 /* All interrupts are masked */
=> 0x00
/*### SDAR */
/*### SDMA Address Register */
/*### Chap. 20.2.4 */
/*### Offset : 0x0000 0904 */
AR = 0xxxxx xxxx /* current system address */
=> 0xFA20 23AC
/*### IDSRx */
/*### IDMA Status Register */
/*### Chap. 20.3.3.2 */
/*### Offset : IDSR1(0x0000 0910) & IDSR2(0x0000 0918) */
AD = 0
DONE = 0
OB = 0
=> 0x00
/*### IDMRx */
/*### IDMA Mask Register */
/*### Chap. 20.3.3.3 */
/*### Offset : IDMR1(0x0000 0914) & IDMR2(0x0000 091C) */
AD = 0
DONE = 0
OB = 0

57
doc/README.SBC8560
View File

@ -1,57 +0,0 @@
The port was tested on Wind River System Sbc8560 board
<www.windriver.com>. U-Boot was installed on the flash memory of the
CPU card (no the SODIMM).
NOTE: Please configure uboot compile to the proper PCI frequency and
setup the appropriate DIP switch settings.
SBC8560 board:
Make sure boards switches are set to their appropriate conditions.
Refer to the Engineering Reference Guide ERG-00300-002. Of particular
importance are: 1) the settings for JP4 (JP4 1-3 and 2-4), which
select the on-board FLASH device (Intel 28F128Jx); 2) The settings
for the Clock SW9 (33 MHz or 66 MHz).
Note: SW9 Settings: 66 MHz
4:1 ratio CCB clocks:SYSCLK
3:1 ration e500 Core:CCB
pos1 - on, pos2 - on, pos3 - off, pos4 - on, pos5 - off, pos6 - on
Note: SW9 Settings: 33 MHz
8:1 ratio CCB clocks:SYSCLK
3:1 ration e500 Core:CCB
pos1 - on, pos2 - on, pos3 - on, pos4 - off, pos5 - off, pos6 - on
Flashing the FLASH device with the "Wind River ICE":
1) Properly connect and configure the Wind River ICE to the target
JTAG port. This includes running the SBC8560 register script. Make
sure target memory can be read and written.
2) Build the u-boot image:
make distclean
make SBC8560_66_config or SBC8560_33_config
make CROSS_COMPILE=.../ELDK3.0/ppc_8xx-/ all
Note: reference is made to the ELDK3.0 compiler. Further, it seems
the ppc_8xx compiler is required for the 85xx (no 85xx
designated compiler in ELDK3.0)
3) Convert the uboot (.elf) file to a uboot.bin file (using
visionClick converter). The bin file should be converted from
fffc0000 to ffffffff
4) Setup the Flash Utility (tools menu) for:
Do a "dc clr" [visionClick] to load the default register settings
Determine the clock speed of the PCI bus and set SW9 accordingly
Note: the speed of the PCI bus defaults to the slowest PCI card
PlayBack the "default" register file for the SBC8560
Select the uboot.bin file with zero bias
Select the initialize Target prior to programming
Select the V28F640Jx (8192 x 8) 1 device FLASH Algorithm
Select the erase base address from FFFC0000 to FFFFFFFF
Select the start address from 0 with size of 4000
5) Erase and Program

17
doc/README.SNTP
View File

@ -1,17 +0,0 @@
To use SNTP support, add a define CFG_CMD_SNTP to CONFIG_COMMANDS in
the configuration file of the board.
The "sntp" command gets network time from NTP time server and
syncronize RTC of the board. This command needs the command line
parameter of server's IP address or environment variable
"ntpserverip". The network time is sent as UTC. So if you want to
set local time to RTC, set the offset in second from UTC to the
enviroment variable "time offset".
If the DHCP server provides time server's IP or time offset, you
don't need to set the above environment variables yourself.
Current limitations of SNTP support:
1. The roundtrip time is ignored.
2. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will
be used.

394
doc/README.Sandpoint8240
View File

@ -1,394 +0,0 @@
The port was tested on a Sandpoint 8240 X3 board, with U-Boot
installed in the flash memory of the CPU card. Please use the
following DIP switch settings:
Motherboard:
SW1.1: on SW1.2: on SW1.3: on SW1.4: on
SW1.5: on SW1.6: on SW1.7: on SW1.8: on
SW2.1: on SW2.2: on SW2.3: on SW2.4: on
SW2.5: on SW2.6: on SW2.7: on SW2.8: on
CPU Card:
SW2.1: OFF SW2.2: OFF SW2.3: on SW2.4: on
SW2.5: OFF SW2.6: OFF SW2.7: OFF SW2.8: OFF
SW3.1: OFF SW3.2: on SW3.3: OFF SW3.4: OFF
SW3.5: on SW3.6: OFF SW3.7: OFF SW3.8: on
The followind detailed description of installation and initial steps
with U-Boot and QNX was provided by Jim Sandoz <sandoz@lucent.com>:
Directions for installing U-Boot on Sandpoint+Unity8240
using the Abatron BDI2000 BDM/JTAG debugger ...
Background and Reference info:
http://u-boot.sourceforge.net/
http://www.abatron.ch/
http://www.abatron.ch/BDI/bdihw.html
http://www.abatron.ch/DataSheets/BDI2000.pdf
http://www.abatron.ch/Manuals/ManGdbCOP-2000C.pdf
http://e-www.motorola.com/collateral/SPX3UM.pdf
http://e-www.motorola.com/collateral/UNITYX4CONFIG.pdf
Connection Diagram:
===========
=== ===== |----- |
| | <---------------> | | | | |
|PC | rs232 | BDI |=============[] | |
| | |2000 | BDM probe | | |
| | <---------------> | | |----- |
=== ethernet ===== | |
| |
===========
Sandpoint X3 with
Unity 8240 proc
PART 1)
DIP Switch Settings:
Sandpoint X3 8240 processor board DIP switch settings, with
U-Boot to be installed in the flash memory of the CPU card:
Motorola Sandpoint X3 Motherboard:
SW1.1: on SW1.2: on SW1.3: on SW1.4: on
SW1.5: on SW1.6: on SW1.7: on SW1.8: on
SW2.1: on SW2.2: on SW2.3: on SW2.4: on
SW2.5: on SW2.6: on SW2.7: on SW2.8: on
Motorola Unity 8240 CPU Card:
SW2.1: OFF SW2.2: OFF SW2.3: on SW2.4: on
SW2.5: OFF SW2.6: OFF SW2.7: OFF SW2.8: OFF
SW3.1: OFF SW3.2: on SW3.3: OFF SW3.4: OFF
SW3.5: on SW3.6: OFF SW3.7: OFF SW3.8: on
PART 2)
Connect the BDI2000 Cable to the Sandpoint/Unity 8240:
BDM Pin 1 on the Unity 8240 processor board is towards the
PCI PMC connectors, or away from the socketed SDRAM, i.e.:
====================
| ---------------- |
| | SDRAM | |
| | | |
| ---------------- |
| |~| |
| |B| ++++++ |
| |D| + uP + |
| |M| +8240+ |
| ~ 1 ++++++ |
| |
| |
| |
| PMC conn ====== |
| ===== ====== |
| |
====================
PART 3)
Setting up the BDI2000, and preparing for TCP/IP network comms:
Connect the BDI2000 to the PC using the supplied serial cable.
Download the BDI2000 software and install it using setup.exe.
[Note: of course you can also use the Linux command line tool
"bdisetup" to configure your BDI2000 - the sources are included on
the floppy disk that comes with your BDI2000. Just in case you don't
have any Windows PC's - like me :-) -- wd ]
Power up the BDI2000; then follow directions to assign the IP
address and related network information. Note that U-Boot
will be loaded to the Sandpoint via tftp. You need to either
use the Abatron-provided tftp application or provide a tftp
server (e.g. Linux/Solaris/*BSD) somewhere on your network.
Once the IP address etc are assigned via the RS232 port,
further communication with the BDI2000 will happen via the
ethernet connection.
PART 4)
Making a TCP/IP network connection to the Abatron BDI2000:
Telnet to the Abatron BDI2000. Assuming that all of the
networking info was loaded via RS232 correctly, you will see
the following (scrolling):
- TARGET: waiting for target Vcc
- TARGET: waiting for target Vcc
PART 5)
Power up the target Sandpoint:
If the BDM connections are correct, the following will now appear:
- TARGET: waiting for target Vcc
- TARGET: waiting for target Vcc
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 => 0xAA
- Bypass check: 0x55 => 0xAA
- JTAG exists check passed
- Target PVR is 0x00810101
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- Waiting for target stop passed
- TARGET: Target PVR is 0x00810101
- TARGET: reseting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
BDI>
PART 6)
Erase the current contents of the flash memory:
BDI>era 0xFFF00000
Erasing flash at 0xfff00000
Erasing flash passed
BDI>era 0xFFF04000
Erasing flash at 0xfff04000
Erasing flash passed
BDI>era 0xFFF06000
Erasing flash at 0xfff06000
Erasing flash passed
BDI>era 0xFFF08000
Erasing flash at 0xfff08000
Erasing flash passed
BDI>era 0xFFF10000
Erasing flash at 0xfff10000
Erasing flash passed
BDI>era 0xFFF20000
Erasing flash at 0xfff20000
Erasing flash passed
PART 7)
Program the flash memory with the U-Boot image:
BDI>prog 0xFFF00000 u-boot.bin bin
Programming u-boot.bin , please wait ....
Programming flash passed
PART 8)
Connect PC to Sandpoint:
Using a crossover serial cable, attach the PC serial port to the
Sandpoint's COM1. Set communications parameters to 8N1 / 9600 baud.
PART 9)
Reset the Unity and begin U-Boot execution:
BDI>reset
- TARGET: processing user reset request
- TARGET: Target PVR is 0x00810101
- TARGET: reseting target passed
- TARGET: processing target init list ....
- TARGET: processing target init list passed
BDI>go
Now see output from U-Boot running, sent via serial port:
U-Boot 1.1.4 (Jan 23 2002 - 18:29:19)
CPU: MPC8240 Revision 1.1 at 264 MHz: 16 kB I-Cache 16 kB D-Cache
Board: Sandpoint 8240 Unity
DRAM: 64 MB
FLASH: 2 MB
PCI: scanning bus0 ...
bus dev fn venID devID class rev MBAR0 MBAR1 IPIN ILINE
00 00 00 1057 0003 060000 13 00000008 00000000 01 00
00 0b 00 10ad 0565 060100 10 00000000 00000000 00 00
00 0f 00 8086 1229 020000 08 80000000 80000001 01 00
In: serial
Out: serial
Err: serial
=>
PART 10)
Set and save any required environmental variables, examples of some:
=> setenv ethaddr 00:03:47:97:D0:79
=> setenv bootfile your_qnx_image_here
=> setenv hostname sandpointX
=> setenv netmask 255.255.255.0
=> setenv ipaddr 192.168.0.11
=> setenv serverip 192.168.0.10
=> setenv gatewayip=192.168.0.1
=> saveenv
Saving Enviroment to Flash...
Un-Protected 1 sectors
Erasing Flash...
done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
=>
**** Example environment: ****
=> printenv
baudrate=9600
bootfile=telemetry
hostname=sp1
ethaddr=00:03:47:97:E4:6B
load=tftp 100000 u-boot.bin
update=protect off all;era FFF00000 FFF3FFFF;cp.b 100000 FFF00000 ${filesize};saveenv
filesize=1f304
gatewayip=145.17.228.1
netmask=255.255.255.0
ipaddr=145.17.228.42
serverip=145.17.242.46
stdin=serial
stdout=serial
stderr=serial
Environment size: 332/8188 bytes
=>
here's some text useful stuff for cut-n-paste:
setenv hostname sandpoint1
setenv netmask 255.255.255.0
setenv ipaddr 145.17.228.81
setenv serverip 145.17.242.46
setenv gatewayip 145.17.228.1
saveenv
PART 11)
Test U-Boot by tftp'ing new U-Boot, overwriting current:
=> protect off all
Un-Protect Flash Bank # 1
=> tftp 100000 u-boot.bin
eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
ARP broadcast 1
TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
gateway 145.17.228.1
Filename 'u-boot.bin'.
Load address: 0x100000
Loading: #########################
done
Bytes transferred = 127628 (1f28c hex)
=> era all
Erase Flash Bank # 1
done
Erase Flash Bank # 2 - missing
=> cp.b 0x100000 FFF00000 1f28c
Copy to Flash... done
=> saveenv
Saving Enviroment to Flash...
Un-Protected 1 sectors
Erasing Flash...
done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
=> reset
You can put these commands into some environment variables;
=> setenv load tftp 100000 u-boot.bin
=> setenv update protect off all\;era FFF00000 FFF3FFFF\;cp.b 100000 FFF00000 \${filesize}\;saveenv
=> saveenv
Then you just have to type "run load" then "run update"
=> run load
eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
ARP broadcast 1
TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
gateway 145.17.228.1
Filename 'u-boot.bin'.
Load address: 0x100000
Loading: #########################
done
Bytes transferred = 127748 (1f304 hex)
=> run update
Un-Protect Flash Bank # 1
Un-Protect Flash Bank # 2
Erase Flash from 0xfff00000 to 0xfff3ffff
done
Erased 7 sectors
Copy to Flash... done
Saving Enviroment to Flash...
Un-Protected 1 sectors
Erasing Flash...
done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
=>
PART 12)
Load OS image (ELF format) via U-Boot using tftp
=> tftp 800000 sandpoint-simple.elf
eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
ARP broadcast 1
TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
gateway 145.17.228.1
Filename 'sandpoint-simple.elf'.
Load address: 0x800000
Loading: #################################################################
#################################################################
#################################################################
########################
done
Bytes transferred = 1120284 (11181c hex)
==>
PART 13)
Begin OS image execution: (note that unless you have the
serial parameters of your OS image set to 9600 (i.e. same as
the U-Boot binary) you will get garbage here until you change
the serial communications speed.
=> bootelf 800000
Loading @ 0x001f0100 (1120028 bytes)
## Starting application at 0x001f1d28 ...
Replace init_hwinfo() with a board specific version
Loading QNX6....
Header size=0x0000009c, Total Size=0x000005c0, #Cpu=1, Type=1
<...loader and kernel messages snipped...>
Welcome to Neutrino on the Sandpoint
#
other information:
CVS Retrieval Notes:
U-Boot's SourceForge CVS repository can be checked out
through anonymous (pserver) CVS with the following
instruction set. The module you wish to check out must
be specified as the modulename. When prompted for a
password for anonymous, simply press the Enter key.
cvs -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot login
cvs -z6 -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot co -P u-boot

415
doc/README.TQM8260
View File

@ -1,415 +0,0 @@
This file contains basic information on the port of U-Boot to TQM8260.
All the changes fit in the common U-Boot infrastructure, providing a
new TQM8260-specific entry in makefiles. To build U-Boot for TQM8260,
type "make TQM8260_config", edit the "include/config_TQM8260.h" file
if necessary, then type "make".
Common file modifications:
--------------------------
The following common files have been modified by this project:
(starting from the ppcboot-0.9.3/ directory)
MAKEALL - TQM8260 entry added
Makefile - TQM8260_config entry added
cpu/mpc8260/Makefile - soft_i2c.o module added
cpu/mpc8260/ether_scc.c - TQM8260-specific definitions added, an obvious
bug fixed (fcr -> scr)
cpu/mpc8260/ether_fcc.c - TQM8260-specific definitions added
include/flash.h - added definitions for the AM29LV640D Flash chip
New files:
----------
The following new files have been added by this project:
(starting from the ppcboot-0.9.3/ directory)
board/tqm8260/ - board-specific directory
board/tqm8260/Makefile - board-specific makefile
board/tqm8260/config.mk - config file
board/tqm8260/flash.c - flash driver (for AM29LV640D)
board/tqm8260/ppcboot.lds - linker script
board/tqm8260/tqm8260.c - ioport and memory initialization
cpu/mpc8260/soft_i2c.c - software i2c EEPROM driver
include/config_TQM8260.h - main configuration file
New configuration options:
--------------------------
CONFIG_TQM8260
Main board-specific option (should be defined for TQM8260).
CONFIG_82xx_CONS_SMC1
If defined, SMC1 will be used as the console
CONFIG_82xx_CONS_SMC2
If defined, SMC2 will be used as the console
CFG_INIT_LOCAL_SDRAM
If defined, the SDRAM on the local bus will be initialized and
mapped at BR2.
Acceptance criteria tests:
--------------------------
The following tests have been conducted to validate the port of U-Boot
to TQM8260:
1. Operation on serial console:
With the CONFIG_82xx_CONS_SMC1 option defined in the main configuration file,
the U-Boot output appeared on the serial terminal connected to COM1 as
follows:
------------------------------------------------------------------------------
=> help
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
and env variables ipaddr and serverip
rarpboot- boot image via network using RARP/TFTP protocol
bootd - boot default, i.e., run 'bootcmd'
loads - load S-Record file over serial line
loadb - load binary file over serial line (kermit mode)
md - memory display
mm - memory modify (auto-incrementing)
nm - memory modify (constant address)
mw - memory write (fill)
cp - memory copy
cmp - memory compare
crc32 - checksum calculation
base - print or set address offset
printenv- print environment variables
setenv - set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase - erase FLASH memory
flinfo - print FLASH memory information
bdinfo - print Board Info structure
iminfo - print header information for application image
coninfo - print console devices and informations
eeprom - EEPROM sub-system
loop - infinite loop on address range
mtest - simple RAM test
icache - enable or disable instruction cache
dcache - enable or disable data cache
reset - Perform RESET of the CPU
echo - echo args to console
version - print monitor version
help - print online help
? - alias for 'help'
=>
------------------------------------------------------------------------------
2. Flash driver operation
The following sequence was performed to test the "flinfo" command:
------------------------------------------------------------------------------
=> flinfo
Bank # 1: AMD 29LV640D (64 M, uniform sector)
Size: 32 MB in 128 Sectors
Sector Start Addresses:
40000000 40040000 (RO) 40080000 400C0000 40100000
40140000 40180000 401C0000 40200000 40240000
40280000 402C0000 40300000 40340000 40380000
403C0000 40400000 40440000 40480000 404C0000
40500000 40540000 40580000 405C0000 40600000
40640000 40680000 406C0000 40700000 40740000
40780000 407C0000 40800000 40840000 40880000
408C0000 40900000 40940000 40980000 409C0000
40A00000 40A40000 40A80000 40AC0000 40B00000
40B40000 40B80000 40BC0000 40C00000 40C40000
40C80000 40CC0000 40D00000 40D40000 40D80000
40DC0000 40E00000 40E40000 40E80000 40EC0000
40F00000 40F40000 40F80000 40FC0000 41000000
41040000 41080000 410C0000 41100000 41140000
41180000 411C0000 41200000 41240000 41280000
412C0000 41300000 41340000 41380000 413C0000
41400000 41440000 41480000 414C0000 41500000
41540000 41580000 415C0000 41600000 41640000
41680000 416C0000 41700000 41740000 41780000
417C0000 41800000 41840000 41880000 418C0000
41900000 41940000 41980000 419C0000 41A00000
41A40000 41A80000 41AC0000 41B00000 41B40000
41B80000 41BC0000 41C00000 41C40000 41C80000
41CC0000 41D00000 41D40000 41D80000 41DC0000
41E00000 41E40000 41E80000 41EC0000 41F00000
41F40000 41F80000 41FC0000
=>
------------------------------------------------------------------------------
The following sequence was performed to test the erase command:
------------------------------------------------------------------------------
=> cp 0 40080000 10
Copy to Flash... done
=> erase 40080000 400bffff
Erase Flash from 0x40080000 to 0x400bffff
.. done
Erased 1 sectors
=> md 40080000
40080000: ffffffff ffffffff ffffffff ffffffff ................
40080010: ffffffff ffffffff ffffffff ffffffff ................
40080020: ffffffff ffffffff ffffffff ffffffff ................
40080030: ffffffff ffffffff ffffffff ffffffff ................
40080040: ffffffff ffffffff ffffffff ffffffff ................
40080050: ffffffff ffffffff ffffffff ffffffff ................
40080060: ffffffff ffffffff ffffffff ffffffff ................
40080070: ffffffff ffffffff ffffffff ffffffff ................
40080080: ffffffff ffffffff ffffffff ffffffff ................
40080090: ffffffff ffffffff ffffffff ffffffff ................
400800a0: ffffffff ffffffff ffffffff ffffffff ................
400800b0: ffffffff ffffffff ffffffff ffffffff ................
400800c0: ffffffff ffffffff ffffffff ffffffff ................
400800d0: ffffffff ffffffff ffffffff ffffffff ................
400800e0: ffffffff ffffffff ffffffff ffffffff ................
400800f0: ffffffff ffffffff ffffffff ffffffff ................
=> cp 0 40080000 10
Copy to Flash... done
=> erase 1:2
Erase Flash Sectors 2-2 in Bank # 1
.. done
=> md 40080000
40080000: ffffffff ffffffff ffffffff ffffffff ................
40080010: ffffffff ffffffff ffffffff ffffffff ................
40080020: ffffffff ffffffff ffffffff ffffffff ................
40080030: ffffffff ffffffff ffffffff ffffffff ................
40080040: ffffffff ffffffff ffffffff ffffffff ................
40080050: ffffffff ffffffff ffffffff ffffffff ................
40080060: ffffffff ffffffff ffffffff ffffffff ................
40080070: ffffffff ffffffff ffffffff ffffffff ................
40080080: ffffffff ffffffff ffffffff ffffffff ................
40080090: ffffffff ffffffff ffffffff ffffffff ................
400800a0: ffffffff ffffffff ffffffff ffffffff ................
400800b0: ffffffff ffffffff ffffffff ffffffff ................
400800c0: ffffffff ffffffff ffffffff ffffffff ................
400800d0: ffffffff ffffffff ffffffff ffffffff ................
400800e0: ffffffff ffffffff ffffffff ffffffff ................
400800f0: ffffffff ffffffff ffffffff ffffffff ................
=> cp 0 40080000 10
Copy to Flash... done
=> cp 0 400c0000 10
Copy to Flash... done
=> erase 1:2-3
Erase Flash Sectors 2-3 in Bank # 1
... done
=> md 40080000
40080000: ffffffff ffffffff ffffffff ffffffff ................
40080010: ffffffff ffffffff ffffffff ffffffff ................
40080020: ffffffff ffffffff ffffffff ffffffff ................
40080030: ffffffff ffffffff ffffffff ffffffff ................
40080040: ffffffff ffffffff ffffffff ffffffff ................
40080050: ffffffff ffffffff ffffffff ffffffff ................
40080060: ffffffff ffffffff ffffffff ffffffff ................
40080070: ffffffff ffffffff ffffffff ffffffff ................
40080080: ffffffff ffffffff ffffffff ffffffff ................
40080090: ffffffff ffffffff ffffffff ffffffff ................
400800a0: ffffffff ffffffff ffffffff ffffffff ................
400800b0: ffffffff ffffffff ffffffff ffffffff ................
400800c0: ffffffff ffffffff ffffffff ffffffff ................
400800d0: ffffffff ffffffff ffffffff ffffffff ................
400800e0: ffffffff ffffffff ffffffff ffffffff ................
400800f0: ffffffff ffffffff ffffffff ffffffff ................
=> md 400c0000
400c0000: ffffffff ffffffff ffffffff ffffffff ................
400c0010: ffffffff ffffffff ffffffff ffffffff ................
400c0020: ffffffff ffffffff ffffffff ffffffff ................
400c0030: ffffffff ffffffff ffffffff ffffffff ................
400c0040: ffffffff ffffffff ffffffff ffffffff ................
400c0050: ffffffff ffffffff ffffffff ffffffff ................
400c0060: ffffffff ffffffff ffffffff ffffffff ................
400c0070: ffffffff ffffffff ffffffff ffffffff ................
400c0080: ffffffff ffffffff ffffffff ffffffff ................
400c0090: ffffffff ffffffff ffffffff ffffffff ................
400c00a0: ffffffff ffffffff ffffffff ffffffff ................
400c00b0: ffffffff ffffffff ffffffff ffffffff ................
400c00c0: ffffffff ffffffff ffffffff ffffffff ................
400c00d0: ffffffff ffffffff ffffffff ffffffff ................
400c00e0: ffffffff ffffffff ffffffff ffffffff ................
400c00f0: ffffffff ffffffff ffffffff ffffffff ................
=>
------------------------------------------------------------------------------
The following sequence was performed to test the Flash programming commands:
------------------------------------------------------------------------------
=> erase 40080000 400bffff
Erase Flash from 0x40080000 to 0x400bffff
.. done
Erased 1 sectors
=> cp 0 40080000 10
Copy to Flash... done
=> md 0
00000000: 00000000 00000104 61100200 01000000 ........a.......
00000010: 00000000 00000000 81140000 82000100 ................
00000020: 01080000 00004000 22800000 00000600 ......@.".......
00000030: 00200800 00000000 10000100 00008000 . ..............
00000040: 00812000 00000200 00020000 80000000 .. .............
00000050: 00028001 00001000 00040400 00000200 ................
00000060: 20480000 00000000 20090000 00142000 H...... ..... .
00000070: 00000000 00004000 24210000 10000000 ......@.$!......
00000080: 02440002 10000000 00200008 00000000 .D....... ......
00000090: 02440900 00000000 30a40000 00004400 .D......0.....D.
000000a0: 04420800 00000000 00000040 00020000 .B.........@....
000000b0: 05020000 00100000 00060000 00000000 ................
000000c0: 00400000 00000000 00080000 00040000 .@..............
000000d0: 10400000 00800004 00000000 00000200 .@..............
000000e0: 80890000 00010004 00080000 00000020 ...............
000000f0: 08000000 10000000 00010000 00000000 ................
=> md 40080000
40080000: 00000000 00000104 61100200 01000000 ........a.......
40080010: 00000000 00000000 81140000 82000100 ................
40080020: 01080000 00004000 22800000 00000600 ......@.".......
40080030: 00200800 00000000 10000100 00008000 . ..............
40080040: ffffffff ffffffff ffffffff ffffffff ................
40080050: ffffffff ffffffff ffffffff ffffffff ................
40080060: ffffffff ffffffff ffffffff ffffffff ................
40080070: ffffffff ffffffff ffffffff ffffffff ................
40080080: ffffffff ffffffff ffffffff ffffffff ................
40080090: ffffffff ffffffff ffffffff ffffffff ................
400800a0: ffffffff ffffffff ffffffff ffffffff ................
400800b0: ffffffff ffffffff ffffffff ffffffff ................
400800c0: ffffffff ffffffff ffffffff ffffffff ................
400800d0: ffffffff ffffffff ffffffff ffffffff ................
400800e0: ffffffff ffffffff ffffffff ffffffff ................
400800f0: ffffffff ffffffff ffffffff ffffffff ................
=>
------------------------------------------------------------------------------
The following sequence was performed to test storage of the environment
variables in Flash:
------------------------------------------------------------------------------
=> setenv foo bar
=> saveenv
Un-Protected 1 sectors
Erasing Flash...
.. done
Erased 1 sectors
Saving Environment to Flash...
Protected 1 sectors
=> reset
...
=> printenv
bootdelay=CONFIG_BOOTDELAY
baudrate=9600
ipaddr=192.168.4.7
serverip=192.168.4.1
ethaddr=66:55:44:33:22:11
foo=bar
stdin=serial
stdout=serial
stderr=serial
Environment size: 170/262140 bytes
=>
------------------------------------------------------------------------------
The following sequence was performed to test image download and run over
Ethernet interface (both interfaces were tested):
------------------------------------------------------------------------------
=> tftpboot 40000 hello_world.bin
ARP broadcast 1
TFTP from server 192.168.2.2; our IP address is 192.168.2.7
Filename 'hello_world.bin'.
Load address: 0x40000
Loading: #############
done
Bytes transferred = 65912 (10178 hex)
=> go 40004
## Starting application at 0x00040004 ...
Hello World
argc = 1
argv[0] = "40004"
argv[1] = "<NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
=>
------------------------------------------------------------------------------
The following sequence was performed to test eeprom read/write commands:
------------------------------------------------------------------------------
=> md 40000
00040000: 00018148 9421ffe0 7c0802a6 bf61000c ...H.!..|....a..
00040010: 90010024 48000005 7fc802a6 801effe8 ...$H...........
00040020: 7fc0f214 7c7f1b78 813f004c 7c9c2378 ....|..x.?.L|.#x
00040030: 807e8000 7cbd2b78 80090010 3b600000 .~..|.+x....;`..
00040040: 7c0803a6 4e800021 813f004c 7f84e378 |...N..!.?.L...x
00040050: 807e8004 80090010 7c0803a6 4e800021 .~......|...N..!
00040060: 7c1be000 4181003c 80bd0000 813f004c |...A..<.....?.L
00040070: 3bbd0004 2c050000 40820008 80be8008 ;...,...@.......
00040080: 80090010 7f64db78 807e800c 3b7b0001 .....d.x.~..;{..
00040090: 7c0803a6 4e800021 7c1be000 4081ffcc |...N..!|...@...
000400a0: 813f004c 807e8010 80090010 7c0803a6 .?.L.~......|...
000400b0: 4e800021 813f004c 80090004 7c0803a6 N..!.?.L....|...
000400c0: 4e800021 2c030000 4182ffec 813f004c N..!,...A....?.L
000400d0: 80090000 7c0803a6 4e800021 813f004c ....|...N..!.?.L
000400e0: 807e8014 80090010 7c0803a6 4e800021 .~......|...N..!
000400f0: 38600000 80010024 7c0803a6 bb61000c 8`.....$|....a..
=> eeprom write 40000 0 40
EEPROM write: addr 00040000 off 0000 count 64 ... done
=> mw 50000 0 1000
=> eeprom read 50000 0 40
EEPROM read: addr 00050000 off 0000 count 64 ... done
=> md 50000
00050000: 00018148 9421ffe0 7c0802a6 bf61000c ...H.!..|....a..
00050010: 90010024 48000005 7fc802a6 801effe8 ...$H...........
00050020: 7fc0f214 7c7f1b78 813f004c 7c9c2378 ....|..x.?.L|.#x
00050030: 807e8000 7cbd2b78 80090010 3b600000 .~..|.+x....;`..
00050040: 00000000 00000000 00000000 00000000 ................
00050050: 00000000 00000000 00000000 00000000 ................
00050060: 00000000 00000000 00000000 00000000 ................
00050070: 00000000 00000000 00000000 00000000 ................
00050080: 00000000 00000000 00000000 00000000 ................
00050090: 00000000 00000000 00000000 00000000 ................
000500a0: 00000000 00000000 00000000 00000000 ................
000500b0: 00000000 00000000 00000000 00000000 ................
000500c0: 00000000 00000000 00000000 00000000 ................
000500d0: 00000000 00000000 00000000 00000000 ................
000500e0: 00000000 00000000 00000000 00000000 ................
000500f0: 00000000 00000000 00000000 00000000 ................
=>
------------------------------------------------------------------------------
Patch per Mon, 06 Aug 2001 17:57:27:
- upgraded Flash support (added support for the following chips:
AM29LV800T/B, AM29LV160T/B, AM29DL322T/B, AM29DL323T/B)
- BCR tweakage for the 8260 bus mode
- SIUMCR tweakage enabling the MI interrupt (IRQ7)
To simplify switching between the bus modes, a new configuration
option (CONFIG_BUSMODE_60x) has been added to the "config_TQM8260.h"
file. If it is defined, BCR will be configured for the 60x mode,
otherwise - for the 8260 mode.
Concerning the SIUMCR modification: it's hard to predict whether it
will induce any problems on the other (60x mode) board. However, the
problems (if they appear) should be easy to notice - if the board
does not boot, it's most likely caused by the DPPC configuration in
SIUMCR.

15
doc/README.VLAN
View File

@ -1,15 +0,0 @@
U-Boot has networking support for VLANs (802.1q), and CDP (Cisco
Discovery Protocol).
You control the sending/receiving of VLAN tagged packets with the
"vlan" environmental variable. When not present no tagging is
performed.
CDP is used mainly to discover your device VLAN(s) when connected to
a Cisco switch.
Note: In order to enable CDP support a small change is needed in the
networking driver. You have to enable reception of the
01:00:0c:cc:cc:cc MAC address which is a multicast address.
Various defines control CDP; see the README section.

235
doc/README.adnpesc1
View File

@ -1,235 +0,0 @@
SSV ADNP/ESC1 Embedded Softcore Computing
Nios Softcore, Altera Cyclone FPGA
Last Update: February 27, 2004
====================================================================
This file contains information regarding U-Boot and the SSV Embedded
Nios Softcore Computing platform ADNP/ESC1. For general Nios
information see doc/README.nios.
Most stuff of this file was borrowed and based on README.dk1s10,
the Altera DK-1S10 related information file.
For those interested in contributing ... see HELP WANTED section
in doc/README.nios.
Contents:
1. Files
2. Memory Organization
3. CPU Variations
4. Examples
5. Programming U-Boot into FLASH with GERMS
6. Autoboot
7. U-Boot environment convention and update philosophy
====================================================================
1. Files
=========
board/ssv/adnpesc1/*
include/configs/ADNPESC1.h
include/configs/ADNPESC1_base_32.h
2. Memory Organization
=======================
For the most part, you can put things pretty much anywhere.
This is pretty flexible for Nios. So here we make some arbitrary
choices & assume that the monitor is placed at the end of a memory
resource. So you must make sure TEXT_BASE is chosen appropriately.
This is very important if you plan to move your memory to another
place as configured at this time!
-The heap is placed below the monitor (U-Boot code).
-Global data is placed below the heap.
-The stack is placed below global data (&grows down).
(see doc/README.adnpesc1_base32 too)
3. CPU Variations
=================
There are more than one NIOS CPU variation for the ADNP/ESC1 possible.
U-Boot supports the following CPU configurations:
- SSV Basis 32 (make ADNPESC1_base_32_config)
- SSV Basis 32 at DNP evaluation base board 2
(make ADNPESC1_DNPEVA2_base_32_config)
4. Examples
============
The hello_world example works fine. To try out you have to change
the default load address from 0x0100_0000 to 0x0204_0000 in
examples/Makefile (the real SDRAM for default board configuration).
5. Programming U-Boot into FLASH with GERMS
============================================
The current version of the ADNP/ESC1 port with the default
configuration settings occupies about 97 KBytes of flash.
A minimal configuration occupies less than 70 KByte
(network, SPI, POST and board command support disabled). You
can save more memory by deactivating the Hu-Shell support and
long command help (CFG_HUSH_PARSER, CFG_LONGHELP).
To program U-Boot into the ADNP/ESC1 flash using GERMS do the
following:
1. Download U-Boot to its target run space in SDRAM:
a. Close jumper RCM_EN# and push the reset button.
b. From the command line, download U-Boot using the
nios-run:
$ nios-run -r u-boot.srec
NOTE: In some cases this want fail. I don't know why,
but try again.
This takes about 1 minute (GERMS is not very speedy here).
After u-boot is downloaded it will be executed. You should
see the following:
U-Boot 1.0.2 (Jan 30 2004 - 12:59:15)
CPU: Nios-32 Rev. 3.3 (0x3038)
Reg file size: 512 LO_LIMIT/HI_LIMIT: 1/30
Board: SSV DilNetPC ADNP/ESC1
Conf.: SSV Base 32 (nios_32)
In: serial
Out: serial
Err: serial
ADNPESC1 >
2. Quit nios-run and start your terminal application (e.g. start
Hyperterminal or minicom).
3. Download the u-boot code to RAM. When using Hyperterminal, do the
following:
a. From the u-boot command prompt start a binary download to SDRAM:
at the SSV Basis 32 to SDRAM:
==> loadb 2000100
b. Download u-boot.bin using kermit.
4. From the U-Boot command prompt, erase flash:
at the SSV Basis 32 from 0x1000000 to 0x103ffff:
==> protect off 1:0-3
==> erase 1:0-3
5. Copy the binary image from SDRAM to flash:
at the SSV Basis 32 from SDRAM:
==> cp.b 2000100 1000000 $filesize
U-Boot will now automatically start when the board is powered on or
reset using the SSV Basis 32 configuration without closed RCM jumper.
To start U-Boot with closed RCM Jumper, enter the following GERMS
command:
+ g 1000000
6. Autoboot
===========
U-Boot will try to boot a valid Nios application from Flash. For this
it will use the deposited Hu-Shell script in environment variable
'bootcmd' which is looking for a valid Nios application identifier
string in Flash and go on at even its entry address. For more
information see the next chapter.
7. U-Boot environment convention and update philosophy
======================================================
U-Boot for the SSV ADNP/ESC1 target knows about many environment
variables used to control the startup process, update process for
raw Nios applications, and optionally file system image updates.
In default configuration there are two Hu-Shell scripts to update
the Nios application and/or the file system image:
1. Update Nios application (ex. the uCLinux kernel):
run 'appl_update'
2. Update optional file system image (ex. RomFS image used by uCLinux):
run 'fs_update'
The Nios application can be any programm code generated in relation
to the Nios application identifier -- the string "Nios" at offset
address 0x0c. To use the scripts like described above in a secure way
you have to check-up the next environment variables:
1. update_allowed
- Update switch -- must be set to '1' (one) to allow any update
- default is '0' (zero)
NOTE: You should avoid to save this variable with non zero
value to Flash. Otherwise it would be allow any
update process at any time!
2. appl_entry_addr
- Nios application area start address (usually in Flash)
- this is the startup address for autoboot
- each Nios application code we want to update will be copied
to this address
- default is CFG_ADNPESC1_NIOS_APPL_ENTRY
3. appl_end_addr
- Nios application area end address (usually in Flash)
- will be used to unprotect/erase the Flash area while updating
- default is CFG_ADNPESC1_NIOS_APPL_END
4. appl_ident_addr
- address of the Nios application identification string
- this is the address checked-up by autoboot
- default is CFG_ADNPESC1_NIOS_APPL_IDENT
5. appl_ident_str
- the Nios application identification string itself
- default is CFG_ADNPESC1_NIOS_IDENTIFIER
6. appl_name
- name of file we have to download/update
- default is ADNPESC1/base32/linux.bin
7. fs_base_addr
- optionally file system area start address (usually in Flash)
- each file system we want to update will be copied to this address
- default is CFG_ADNPESC1_FILESYSTEM_BASE
8. fs_end_addr
- optionally file system area end address (usually in Flash)
- will be used to unprotect/erase the Flash area while updating
- default is CFG_ADNPESC1_FILESYSTEM_END
9. fs_name
- name of file we have to download/update
- default is ADNPESC1/base32/romfs.img

469
doc/README.adnpesc1_base32
View File

@ -1,469 +0,0 @@
TODO: specify IDE i/f
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[5]
CPU: "DNP_ESC1"
32 bit NIOS for 50 MHz
512 Byte for register file (30 levels)
with out instruction cache
with out data cache
2 KByte On Chip ROM with GERMS boot monitor
with out On Chip RAM
MSTEP multiplier
no Debug Core
no On Chip Instrumentation (OCI)
U-Boot CFG: CFG_NIOS_CPU_CLK = 50000000
CFG_NIOS_CPU_ICACHE = (not present)
CFG_NIOS_CPU_DCACHE = (not present)
CFG_NIOS_CPU_REG_NUMS = 512
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
IRQ: Nr. | used by
------+--------------------------------------------------------
16 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 16
17 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 17
18 | UART1 | CFG_NIOS_CPU_UART1_IRQ = 18
20 | LAN91C111 | CFG_NIOS_CPU_LAN0_IRQ =
| PIO6 | CFG_NIOS_CPU_PIO6_IRQ = 20
25 | SPI0 | CFG_NIOS_CPU_SPI0_IRQ = 25
31 | PIO7 | CFG_NIOS_CPU_PIO7_IRQ = 31
32 | PIO8 | CFG_NIOS_CPU_PIO8_IRQ = 32
33 | PIO9 | CFG_NIOS_CPU_PIO9_IRQ = 33
34 | PIO10 | CFG_NIOS_CPU_PIO10_IRQ = 34
35 | PIO11 | CFG_NIOS_CPU_PIO11_IRQ = 35
36 | PIO12 | CFG_NIOS_CPU_PIO12_IRQ =
| IDE0 | CFG_NIOS_CPU_IDE0_IRQ = 36
37 | PIO13 | CFG_NIOS_CPU_PIO13_IRQ =
| IDE1 | CFG_NIOS_CPU_IDE1_IRQ = 37
MEMORY: 8 MByte Flash
16 MByte SDRAM
Timer: TIMER0: high priority programmable timer (IRQ16)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 0
CFG_NIOS_CPU_USER_TIMER = (not present)
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | PORTA: 8 in/outputs for general purpose usage
PIO1 | PORTB: 8 in/outputs for general purpose usage
PIO2 | PORTC: 4 in/outputs for general purpose usage
PIO3 | RCM: 1 input for RCM_EN# jumper (Req.Conf.Mon.)
PIO4 | WDTENA: 1 output to enable the on-board watchdog
PIO5 | WDTTRIG: 1 output to trigger the on-board watchdog
PIO6 | LAN0INT: 1 input for LAN91C111 irq input (IRQ20)
PIO7 | INT1: 1 input for general purpose irq (IRQ31)
PIO8 | INT2: 1 input for general purpose irq (IRQ32)
PIO9 | INT3: 1 input for general purpose irq (IRQ33)
PIO10| INT4: 1 input for general purpose irq (IRQ34)
PIO11| INT5: 1 input for general purpose irq (IRQ35)
PIO12| INT6: 1 input for general purpose irq (IRQ36)
| IDE0INT: (same) for IDE0 irq input
PIO13| INT7: 1 input for general purpose irq (IRQ37)
| IDE1INT: (same) for IDE1 irq input
U-Boot CFG: CFG_NIOS_CPU_PORTA_PIO = 0
CFG_NIOS_CPU_PORTB_PIO = 1
CFG_NIOS_CPU_PORTC_PIO = 2
CFG_NIOS_CPU_RCM_PIO = 3
CFG_NIOS_CPU_WDTENA_PIO = 4
CFG_NIOS_CPU_WDTTRIG_PIO = 5
CFG_NIOS_CPU_LED_PIO = (not present)
UART: UART0: fixed baudrate of 115200, fixed protocol 8N1, RTS/CTS (IRQ17)
UART1: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ18)
SPI: SPI0: master capable, 1 slave selectable, 250kHz target clock,
2 usec targets delay between slave select and clock,
data is transferred MSB-first / LSB-last (IRQ25)
LAN: SMsC LAN91C111 with:
- without offset
- data bus width 16 bit (on-board hard wired at 32 bit bus)
- !!! 32 bit bus access --> each address * 2 !!!
IDE: (TODO)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external extension - - - - - - - - - - - - - - - - - - -
0x44000000 ---32-----------16|15------------0-
| | | \
: (real size : : |
EXT3 (CS4) : and content : : > CFG_NIOS_CPU_CS3_SIZE
: unknown) : : | = 0x01000000
| | | /
0x43000000 ---32-----------16|15------------0- CFG_NIOS_CPU_CS3_BASE
| | | \
: (real size : : |
EXT2 (CS3) : and content : : > CFG_NIOS_CPU_CS2_SIZE
: unknown) : : | = 0x01000000
| | | /
0x42000000 ---32-----------16|15------------0- CFG_NIOS_CPU_CS2_BASE
| | | \
: (real size : : |
EXT1 (CS2) : and content : : > CFG_NIOS_CPU_CS1_SIZE
: unknown) : : | = 0x01000000
| | | /
0x41000000 ---32-----------16|15------------0- CFG_NIOS_CPU_CS1_BASE
| | | \
: (real size : : |
EXT0 (CS1) : and content : : > CFG_NIOS_CPU_CS0_SIZE
: unknown) : : | = 0x01000000
| | | /
0x40000000 ---32-----------16|15------------0- CFG_NIOS_CPU_CS0_BASE
| |
: gap :
: :
- - - - - - - - - - - external memory - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x03000000 ---32-----------16|15------------0- CFG_NIOS_CPU_STACK
| . | \
| . | | (U-Boot run-time system)
| . | |
| . | > CFG_MONITOR_LEN
| . | | = 0x00040000
| . | |
| . | /
0x02fc0000 --+32-----------16|15------------0+ TEXT_BASE
| . | \
| . | > CFG_MALLOC_LEN (heap)
| . | /
--+32-----------16|15------------0+
| . | \
| . | > CFG_GBL_DATA_SIZE (global)
| . | /
--+32-----------16|15------------0+ CFG_INIT_SP (u-boot stack)
| . | \ \
| . | | |
| . | | > stack area
| . | | |
| . | | V
| . | |
| . | |
SDRAM | . | > CFG_NIOS_CPU_SDRAM_SIZE
| . | | = 0x01000000
| . | |
0x02000100 |- - - - - - - - - - - - - - - -+-|-
| . | | \
| . | | |
| . | | > CFG_NIOS_CPU_VEC_SIZE
| . | | | = 0x00000100
| | / /
0x02000000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_VEC_BASE
0x02000000 ---32-----------16|15------------0- CFG_NIOS_CPU_SDRAM_BASE
| | \
: gap : > (space for 2nd Flash)
| | /
0x01800000 ---32-----------16|15------------0-
| sector 127 | \
+ 0x7f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 1 : | | = 0x00800000
+ 0x010000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x10000) | /
0x01000000 ---8-------------4|3-------------0- CFG_NIOS_CPU_FLASH_BASE
| |
: gap :
: :
- - - - - - - - - - - external i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00010020 ---32-----------16|15------------0-
| | \
| register bank | |
| size = (real_size << 1) | |
| real_size = 0x10 | |
| +--------.---.---.--- | |
| | bank 0 \ 1 \ 2 \ 3 \ | |
| |---------------------------+ | |
LAN91C111 | | BANK | RESERVED | | > na_enet_size
| |- - - - - - -|- - - - - - -| | | = 0x00000020
| | RPCR | MIR | | |
| |- - - - - - -|- - - - - - -| | |
| | COUNTER | RCR | | |
| |- - - - - - -|- - - - - - -| | |
| | EPH STATUS | TCR | | |
| +---------------------------+ | /
0x00010000 ---32-----------16|15------------0- CFG_NIOS_CPU_LAN0_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00001040 ---32-----------16|15------------0-
| | | \
: : : |
IDE1 i/f : : : > 0x00000020
[5] : : : |
| | | /
0x00001020 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE1
| | | \
: : : |
IDE0 i/f : : : > 0x00000020
[5] : : : |
| | | /
0x00001000 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE0
| |
: gap :
| |
0x00000980 ---32-----------16|15------------0-
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO13 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000970 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO13
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO12 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000960 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO12
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO11 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000950 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO11
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO10 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000940 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO10
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO9 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000930 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO9
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO8 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000920 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO8
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO7 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000910 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO7
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO6 | interruptmask (1 bit) (rw) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000900 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO6
| |
: gap :
| |
0x000008e0 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| endofpacket (16 bit) (rw) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| slaveselect (1 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
SPI0 | (reserved) | |
[4] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| control (11 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (9 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (16 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (16 bit) (ro) | /
0x000008c0 ---32-----------16|15------------0- CFG_NIOS_CPU_SPI0
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO5 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x000008b0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO5
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO4 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x000008a0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO4
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO3 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x00000890 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO3
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO2 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (4 bit) (rw) | /
0x00000880 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO2
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (8 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (8 bit) (rw) | /
0x00000870 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | (unused) | |
[3] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (8 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (8 bit) (rw) | /
0x00000860 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[2] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00000840 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART1 | (unused) | > 0x00000020
[1] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00000820 ---32-----------16|15------------0- CFG_NIOS_CPU_UART1
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[1] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00000800 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip memory 1 - - - - - - - - - - -
0x00000800 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > CFG_NIOS_CPU_ROM_SIZE
| : | | = 0x00000800
| : | /
0x00000000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_RST_VECT
0x00000000 ---32-----------16|15------------0- CFG_NIOS_CPU_ROM_BASE
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x01800000 ---8-------------4|3-------------0-
| : | \
| : | |
| : | > 6 MByte ROM FS
| : | |
| : | /
0x01200000 --+- - - - - - - -:- - - - - - - -+- - file system image(s)
| : | \
| : | |
| : | > 1728 kByte ucLinux
| : | |
| : | /
0x01050000 --+- - - - - - - -:- - - - - - - -+- - os image(s)
| : | \
0x01040000 --+- - - - - - - -:- - - - - - - -+-|- u-boot environment
| : | |
| : | > 320 kByte U-Boot
| : | |
| : | |
| : | /
0x01000000 --+- - - - - - - -:- - - - - - - -+- - u-boot _start()
0x01000000 ---8-------------4|3-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[2] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[3] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[4] http://www.altera.com/literature/ds/ds_nios_spi.pdf
[5] http://www.t13.org/index.html
===============================================================================
Stephan Linz <linz@li-pro.net>

482
doc/README.alaska8220
View File

@ -1,482 +0,0 @@
Freescale Alaska MPC8220 board
==============================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created 9/21/04
===========================================
Changed files:
==============
- Makefile added MPC8220 and Alaska8220_config
- MAKEALL added MPC8220 and Alaska8220
- README added CONFIG_MPC8220, Alaska8220_config
- common/cmd_bdinfo.c added board information members for MPC8220
- common/cmd_bootm.c added clocks for MPC8220 in do_bootm_linux()
- include/common.h added CONFIG_MPC8220
- include/asm-ppc/u-boot.h added board information members for MPC8220
- include/asm-ppc/global_data.h added global variables - inp_clk, pci_clk,
vco_clk, pev_clk, flb_clk, and bExtUart
- lib_ppc/board.c added CONFIG_MPC8220 support
- net/eth.c added FEC support for MPC8220
Added files:
============
- board/alaska directory for Alaska MPC8220
- board/alaska/alaska.c Alaska dram and BATs setup
- board/alaska/extserial.c external serial (debug card serial) support
- board/alaska/flash.c Socket (AMD) and Onboard (INTEL) flash support
- board/alaska/serial.c to determine which int/ext serial to use
- board/alaska/Makefile Makefile
- board/alaska/config.mk config make
- board/alaska/u-boot.lds Linker description
- cpu/mpc8220/dma.h multi-channel dma header file
- cpu/mpc8220/dramSetup.h dram setup header file
- cpu/mpc8220/fec.h MPC8220 FEC header file
- cpu/mpc8220/cpu.c cpu specific code
- cpu/mpc8220/cpu_init.c Flexbus ChipSelect and Mux pins setup
- cpu/mpc8220/dramSetup.c MPC8220 DDR SDRAM setup
- cpu/mpc8220/fec.c MPC8220 FEC driver
- cpu/mpc8220/i2c.c MPC8220 I2C driver
- cpu/mpc8220/interrupts.c interrupt support (not enable)
- cpu/mpc8220/loadtask.c load dma
- cpu/mpc8220/speed.c system, pci, flexbus, pev, and cpu clock
- cpu/mpc8220/traps.c exception
- cpu/mpc8220/uart.c MPC8220 UART driver
- cpu/mpc8220/Makefile Makefile
- cpu/mpc8220/config.mk config make
- cpu/mpc8220/fec_dma_task.S MPC8220 FEC multi-channel dma program
- cpu/mpc8220/io.S io functions
- cpu/mpc8220/start.S start up
- include/mpc8220.h
- include/asm-ppc/immap_8220.h
- include/configs/Alaska8220.h
1. SWITCH SETTINGS
==================
1.1 SW1: 0 - Boot from Socket Flash (AMD) or 1 - Onboard Flash (INTEL)
SW2: 0 - Select MPC8220 UART or 1 - Debug Card UART
SW3: unsed
SW4: 0 - 1284 or 1 - FEC1
SW5: 0 - PEV or 1 - FEC2
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. For the initial bringup, we adopted a consistent memory scheme between u-boot and
linux kernel, you can customize it based on your system requirements:
DDR: 0x00000000-0x1fffffff (max 512MB)
MBAR: 0xf0000000-0xf0027fff (128KB)
CPLD: 0xf1000000-0xf103ffff (256KB)
FPGA: 0xf2000000-0xf203ffff (256KB)
Flash: 0xfe000000-0xffffffff (max 32MB)
3. DEFINITIONS AND COMPILATION
==============================
3.1 Explanation on NEW definitions in include/configs/alaska8220.h
CONFIG_MPC8220 MPC8220 specific
CONFIG_ALASKA8220 Alaska board specific
CFG_MPC8220_CLKIN Define Alaska Input Clock
CONFIG_PSC_CONSOLE Enable MPC8220 UART
CONFIG_EXTUART_CONSOLE Enable External 16552 UART
CFG_AMD_BOOT To determine the u-boot is booted from AMD or Intel
CFG_MBAR MBAR base address
CFG_DEFAULT_MBAR Reset MBAR base address
3.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot-1-1-x
make distclean
make Alaska8220_config
make
4. SCREEN DUMP
==============
4.1 Alaska MPC8220 board
Boot from AMD (NOTE: May not show exactly the same)
U-Boot 1.1.1 (Sep 22 2004 - 22:14:41)
CPU: MPC8220 (JTAG ID 1640301d) at 300 MHz
Bus 120 MHz, CPU 300 MHz, PCI 30 MHz, VCO 480 MHz
Board: Alaska MPC8220 Evaluation Board
I2C: 93 kHz, ready
DRAM: 256 MB
Reserving 167k for U-Boot at: 0ffd6000
FLASH: 16.5 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
=> flinfo
Bank # 1: INTEL 28F128J3A
Size: 8 MB in 64 Sectors
Sector Start Addresses:
FE000000 FE020000 FE040000 FE060000 FE080000
FE0A0000 FE0C0000 FE0E0000 FE100000 FE120000
FE140000 FE160000 FE180000 FE1A0000 FE1C0000
FE1E0000 FE200000 FE220000 FE240000 FE260000
FE280000 FE2A0000 FE2C0000 FE2E0000 FE300000
FE320000 FE340000 FE360000 FE380000 FE3A0000
FE3C0000 FE3E0000 FE400000 FE420000 FE440000
FE460000 FE480000 FE4A0000 FE4C0000 FE4E0000
FE500000 FE520000 FE540000 FE560000 FE580000
FE5A0000 FE5C0000 FE5E0000 FE600000 FE620000
FE640000 FE660000 FE680000 FE6A0000 FE6C0000
FE6E0000 FE700000 FE720000 FE740000 FE760000
FE780000 FE7A0000 FE7C0000 FE7E0000
Bank # 2: INTEL 28F128J3A
Size: 8 MB in 64 Sectors
Sector Start Addresses:
FE800000 FE820000 FE840000 FE860000 FE880000
FE8A0000 FE8C0000 FE8E0000 FE900000 FE920000
FE940000 FE960000 FE980000 FE9A0000 FE9C0000
FE9E0000 FEA00000 FEA20000 FEA40000 FEA60000
FEA80000 FEAA0000 FEAC0000 FEAE0000 FEB00000
FEB20000 FEB40000 FEB60000 FEB80000 FEBA0000
FEBC0000 FEBE0000 FEC00000 FEC20000 FEC40000
FEC60000 FEC80000 FECA0000 FECC0000 FECE0000
FED00000 FED20000 FED40000 FED60000 FED80000
FEDA0000 FEDC0000 FEDE0000 FEE00000 FEE20000
FEE40000 FEE60000 FEE80000 FEEA0000 FEEC0000
FEEE0000 FEF00000 (RO) FEF20000 (RO) FEF40000 FEF60000
FEF80000 FEFA0000 FEFC0000 FEFE0000 (RO)
Bank # 3: AMD AMD29F040B
Size: 0 MB in 7 Sectors
Sector Start Addresses:
FFF00000 (RO) FFF10000 (RO) FFF20000 (RO) FFF30000 FFF40000
FFF50000 FFF60000
Bank # 4: AMD AMD29F040B
Size: 0 MB in 1 Sectors
Sector Start Addresses:
FFF70000 (RO)
=> bdinfo
memstart = 0xF0009800
memsize = 0x10000000
flashstart = 0xFFF00000
flashsize = 0x01080000
flashoffset = 0x00025000
sramstart = 0xF0020000
sramsize = 0x00008000
bootflags = 0x00000001
intfreq = 300 MHz
busfreq = 120 MHz
inpfreq = 30 MHz
flbfreq = 30 MHz
pcifreq = 30 MHz
vcofreq = 480 MHz
pevfreq = 81 MHz
ethaddr = 00:E0:0C:BC:E0:60
eth1addr = 00:E0:0C:BC:E0:61
IP addr = 192.162.1.2
baudrate = 115200 bps
=> printenv
bootargs=root=/dev/ram rw
bootdelay=5
baudrate=115200
ethaddr=00:e0:0c:bc:e0:60
eth1addr=00:e0:0c:bc:e0:61
ipaddr=192.162.1.2
serverip=192.162.1.1
gatewayip=192.162.1.1
netmask=255.255.255.0
hostname=Alaska
stdin=serial
stdout=serial
stderr=serial
ethact=FEC ETHERNET
Environment size: 268/65532 bytes
=> setenv ipaddr 192.160.1.2
=> setenv serverip 192.160.1.1
=> setenv gatewayip 192.160.1.1
=> saveenv
Saving Environment to Flash...
.
Un-Protected 1 sectors
Erasing Flash...
Erasing sector 0 ... done
Erased 1 sectors
Writing to Flash... done
.
Protected 1 sectors
=> tftp 0x10000 linux.elf
Using FEC ETHERNET device
TFTP from server 192.160.1.1; our IP address is 192.160.1.2; sending through gateway 192.160.1.1
Filename 'linux.elf'.
Load address: 0x10000
Loading: invalid RARP header
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
done
Bytes transferred = 2917494 (2c8476 hex)
=> bootelf
Loading .text @ 0x00a00000 (23820 bytes)
Loading .data @ 0x00a06000 (2752512 bytes)
Clearing .bss @ 0x00ca6000 (12764 bytes)
## Starting application at 0x00a00000 ...
Collect some entropy from RAM........done
loaded at: 00A00000 00CA91DC
zimage at: 00A06A93 00AD7756
initrd at: 00AD8000 00CA5565
avail ram: 00CAA000 014AA000
Linux/PPC load: ip=off console=ttyS0,115200
Uncompressing Linux...done.
Now booting the kernel
Total memory in system: 256 MB
Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.21-rc1 (r61688@bluesocks.sps.mot.com) (gcc version 3.3.1) #17 Wed Sep 8 11:49:16 CDT 2004
Motorola Alaska port (C) 2003 Motorola, Inc.
CPLD rev 3
CPLD switches 0x1b
Set Pin Mux for FEC1
Set Pin Mux for FEC2
Alaska Pin Multiplexing:
Port Configuration Register 0 = 0
Port Configuration Register 1 = 0
Port Configuration Register 2 = 0
Port Configuration Register 3 = 50000000
Port Configuration Register 3 - PCI = 51400180
Setup Alaska FPGA PIC:
Interrupt Enable Register *(u32) = 0
Interrupt Status Register = 2f0000
Interrupt Enable Register in_be32 = 0
Interrupt Status Register = 2f0000
Interrupt Enable Register in_le32 = 0
Interrupt Status Register = 2f00
Interrupt Enable Register readl = 0
Interrupt Status Register = 2f00
Interrupt Enable Register = 0
Interrupt Status Register = 2f0000
Setup Alaska PCI Controller:
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ip=off console=ttyS0,115200
Using XLB clock (120.00 MHz) to set up decrementer
Calibrating delay loop... 199.88 BogoMIPS
Memory: 254792k available (1476k kernel code, 708k data, 228k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: (pcibios_init) Global-Hose = 0xc029d000
Scanning bus 00
Fixups for bus 00
Bus scan for 00 returning with max=00
PCI: (pcibios_init) finished pci_scan_bus(hose->first_busno = 0, hose->ops = c01a1a74, hose = c029d000)
PCI: (pcibios_init) PCI Bus Count = 0 =?= Next Bus# = 1
PCI: (pcibios_init@pci_fixup_irqs) finished machine dependent PCI interrupt routing!
PCI: bridge rsrc 81000000..81ffffff (100), parent c01a7f88
PCI: bridge rsrc 84000000..87ffffff (200), parent c01a7fa4
PCI: (pcibios_init) finished allocating and assigning resources!
initDma!
Using 90 DMA buffer descriptors
descUsed f0023600, descriptors f002360c freeSram f0024140
unmask SDMA tasks: 0xf0008018 = 0x6f000000
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
pty: 256 Unix98 ptys configured
tracek: Copyright (C) Motorola, 2003.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xf1001008 (irq = 73) is a ST16650
ttyS01 at 0xf1001010 (irq = 74) is a ST16650
elp-fpanel: Copyright (C) Motorola, 2003.
fpanel: fpanelWait timeout
elp-engine: Copyright (C) Motorola, 2003.
Video disabled due to configuration switch 4
Alpine 1284 driver: Copyright (C) Motorola, 2003.
1284 disabled due to configuration switch 5
Alpine USB driver: Copyright (C) Motorola, 2003.
OK
USB: Descriptor download completed OK
enable_irq(41) unbalanced
enable_irq(75) unbalanced
elp-dmaram: Copyright (C) Motorola, 2003.
Total memory in system: 256 MB
elp_dmaram: offset is 0x10000000, size is 0
Xicor NVRAM driver: Copyright (C) Motorola, 2003.
elp-video: Copyright (C) Motorola, 2003.
Video disabled due to configuration switch 4
elp-pfm: Copyright (C) Motorola, 2003.
paddle: Copyright (C) Motorola, 2001, present.
RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
loop: loaded (max 8 devices)
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
init_alaska_mtd: chip probing count 0
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
init_alaska_mtd: bank1, name:ALASKA0, size:16777216bytes
ALASKA flash0: Using Static image partition definition
Creating 3 MTD partitions on "ALASKA0":
0x00000000-0x00280000 : "kernel"
0x00280000-0x00fe0000 : "user"
0x00fe0000-0x01000000 : "signature"
mgt_fec_module_init
mgt_fec_init()
mgt_fec_init
mgt_init_fec_dev(0xc05f6000,0)
dev c05f6000 fec_priv c05f6160 fec f0009000
mgt_init_fec_dev(0xc05f6800,1)
dev c05f6800 fec_priv c05f6960 fec f0009800
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1845k freed
JFFS: Trying to mount a non-mtd device.
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 228k init
INIT: version 2.78 booting
INIT: Entering runlevel: 1
"Space, a great big place of unknown stuff." -Dexter, for our MotD.
[01/Jan/1970:00:00:01 +0000] boa: server version Boa/0.94.8.3
[01/Jan/1970:00:00:01 +0000] boa: server built Sep 7 2004 at 17:40:55.
[01/Jan/1970:00:00:01 +0000] boa: starting server pid=28, port 80
Mounting flash filesystem, will take a minute...
/etc/rc: line 30: /dev/lp0: No such devish-2.05b#
sh-2.05b# ifup eth0
client (v0.9.9-pre) started
adapter index 2
adapter hardware address 00:e0:0c:bc:e0:60
execle'ing /usr/share/udhcpc/default.script
/sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:E0:0C:BC:E0:60
BROADCAST MULTICAST MTU:1500 Metric:1
mgt_fec_open
Rfec request irq
X fec_open: rcv_ring_size 8, xmt_ring_size 8
packmgt_fec_open(): call netif_start_queue()
ets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Base address:0x9000
/sbin/ifconfig eth0 up
entering raw listen mode
Opening raw socket on ifindex 2
adding option 0x35
adding option 0x3d
adding option 0x3c
Sending discover...
Waiting on select...
unrelated/bogus packet
Waiting on select...
oooooh!!! got some!
adding option 0x35
adding option 0x3d
adding option 0x3c
adding option 0x32
adding option 0x36
Sending select for 163.12.48.146...
Waiting on select...
oooooh!!! got some!
Waiting on select...
oooooh!!! got some!
Lease of 163.12.48.146 obtained, lease time 345600
execle'ing /usr/share/udhcpc/default.script
/sbin/ifconfig eth0 163.12.48.146 netmask 255.255.254.0
/sbin/ifconfig eth0 up
deleting routers
/sbin/route del default
/sbin/route add default gw 163.12.49.254 dev eth0
adding dns 163.12.252.230
adding dns 192.55.22.4
adding dns 192.5.249.4
entering none listen mode
sh-2.05b#
5. REPROGRAM U-BOOT
===================
5.1 Reprogram u-boot (boot from AMD)
1. Unprotect the boot sector
=> protect off bank 3
2. Download new u-boot binary file
=> tftp 0x10000 u-boot.bin
3. Erase bootsector (max 7 sectors)
=> erase 0xfff00000 0xfff6ffff
4. Program the u-boot to flash
=> cp.b 0x10000 0xfff00000
5. Reset for the new u-boot to take place
=> reset
5.2 Reprogram u-boot (boot from AMD program at INTEL)
1. Unprotect the boot sector
=> protect off bank 2
2. Download new u-boot binary file
=> tftp 0x10000 u-boot.bin
3. Erase bootsector (max 7 sectors)
=> erase 0xfef00000 0xfefdffff
4. Program the u-boot to flash
=> cp.b 0x10000 0xfef00000
5. Reset for the new u-boot to take place
=> reset
5.3 Reprogram u-boot (boot from INTEL)
1. Unprotect the boot sector
=> protect off bank 4
2. Download new u-boot binary file
=> tftp 0x10000 u-boot.bin
3. Erase bootsector (max 7 sectors)
=> erase 0xfff00000 0xfffdffff
4. Program the u-boot to flash
=> cp.b 0x10000 0xfff00000
5. Reset for the new u-boot to take place
=> reset
5.4 Reprogram u-boot (boot from INTEL program at AMD)
1. Unprotect the boot sector
=> protect off bank 1
2. Download new u-boot binary file
=> tftp 0x10000 u-boot.bin
3. Erase bootsector (max 7 sectors)
=> erase 0xfe080000 0xfe0effff
4. Program the u-boot to flash
=> cp.b 0x10000 0xfe080000
5. Reset for the new u-boot to take place
=> reset

12
doc/README.amigaone
View File

@ -1,12 +0,0 @@
AmigaOne U-Boot and the SciTech emulator
The directory board/MAI/bios_emulator contains the source code
of the SciTech x86 emulator. This emulator is normally available
under a BSD license. However, SciTech kindly gave us permission
to use their emulator in PPCBoot for the AmigaOne. It's available
in this form only under GPL.
Thanks to Kendall Bennett and the rest of the team at SciTech.
See http://www.scitechsoft.com for their web site
The GPL license can be found at http://www.gnu.org/licenses/gpl.html

158
doc/README.autoboot
View File

@ -1,158 +0,0 @@
/*
* (C) Copyright 2001
* Dave Ellis, SIXNET, dge@sixnetio.com
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
Using autoboot configuration options
====================================
The basic autoboot configuration options are documented in the main
U-Boot README. See it for details. They are:
bootdelay
bootcmd
CONFIG_BOOTDELAY
CONFIG_BOOTCOMMAND
Some additional options that make autoboot safer in a production
product are documented here.
Why use them?
-------------
The basic autoboot feature allows a system to automatically boot to
the real application (such as Linux) without a user having to enter
any commands. If any key is pressed before the boot delay time
expires, U-Boot stops the autoboot process, gives a U-Boot prompt
and waits forever for a command. That's a good thing if you pressed a
key because you wanted to get the prompt.
It's not so good if the key press was a stray character on the
console serial port, say because a user who knows nothing about
U-Boot pressed a key before the system had time to boot. It's even
worse on an embedded product that doesn't have a console during
normal use. The modem plugged into that console port sends a
character at the wrong time and the system hangs, with no clue as to
why it isn't working.
You might want the system to autoboot to recover after an external
configuration program stops autoboot. If the configuration program
dies or loses its connection (modems can disconnect at the worst
time) U-Boot will patiently wait forever for it to finish.
These additional configuration options can help provide a system that
boots when it should, but still allows access to U-Boot.
What they do
------------
CONFIG_BOOT_RETRY_TIME
CONFIG_BOOT_RETRY_MIN
"bootretry" environment variable
These options determine what happens after autoboot is
stopped and U-Boot is waiting for commands.
CONFIG_BOOT_RETRY_TIME must be defined to enable the boot
retry feature. If the environment variable "bootretry" is
found then its value is used, otherwise the retry timeout is
CONFIG_BOOT_RETRY_TIME. CONFIG_BOOT_RETRY_MIN is optional and
defaults to CONFIG_BOOT_RETRY_TIME. All times are in seconds.
If the retry timeout is negative, the U-Boot command prompt
never times out. Otherwise it is forced to be at least
CONFIG_BOOT_RETRY_MIN seconds. If no valid U-Boot command is
entered before the specified time the boot delay sequence is
restarted. Each command that U-Boot executes restarts the
timeout.
If CONFIG_BOOT_RETRY_TIME < 0 the feature is there, but
doesn't do anything unless the environment variable
"bootretry" is >= 0.
CONFIG_AUTOBOOT_KEYED
CONFIG_AUTOBOOT_PROMPT
CONFIG_AUTOBOOT_DELAY_STR
CONFIG_AUTOBOOT_STOP_STR
CONFIG_AUTOBOOT_DELAY_STR2
CONFIG_AUTOBOOT_STOP_STR2
"bootdelaykey" environment variable
"bootstopkey" environment variable
"bootdelaykey2" environment variable
"bootstopkey2" environment variable
These options give more control over stopping autoboot. When
they are used a specific character or string is required to
stop or delay autoboot.
Define CONFIG_AUTOBOOT_KEYED (no value required) to enable
this group of options. CONFIG_AUTOBOOT_DELAY_STR,
CONFIG_AUTOBOOT_STOP_STR or both should be specified (or
specified by the corresponding environment variable),
otherwise there is no way to stop autoboot.
CONFIG_AUTOBOOT_PROMPT is displayed before the boot delay
selected by CONFIG_BOOTDELAY starts. If it is not defined
there is no output indicating that autoboot is in progress.
If "%d" is included, it is replaced by the number of seconds
remaining before autoboot will start, but it does not count
down the seconds. "autoboot in %d seconds\n" is a reasonable
prompt.
If CONFIG_AUTOBOOT_DELAY_STR or "bootdelaykey" is specified
and this string is received from console input before
autoboot starts booting, U-Boot gives a command prompt. The
U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is
used, otherwise it never times out.
If CONFIG_AUTOBOOT_STOP_STR or "bootstopkey" is specified and
this string is received from console input before autoboot
starts booting, U-Boot gives a command prompt. The U-Boot
prompt never times out, even if CONFIG_BOOT_RETRY_TIME is
used.
The string recognition is not very sophisticated. If a
partial match is detected, the first non-matching character
is checked to see if starts a new match. There is no check
for a shorter partial match, so it's best if the first
character of a key string does not appear in the rest of the
string.
Using the CONFIG_AUTOBOOT_DELAY_STR2 #define or the
"bootdelaykey2" environment variable and/or the
CONFIG_AUTOBOOT_STOP_STR2 #define or the "bootstopkey"
environment variable you can specify a second, alternate
string (which allows you to have two "password" strings).
CONFIG_ZERO_BOOTDELAY_CHECK
If this option is defined, you can stop the autoboot process
by hitting a key even in that case when "bootdelay" has been
set to 0. You can set "bootdelay" to a negative value to
prevent the check for console input.
CONFIG_RESET_TO_RETRY
(Only effective when CONFIG_BOOT_RETRY_TIME is also set)
After the countdown timed out, the board will be reset to restart
again.

15
doc/README.bamboo
View File

@ -1,15 +0,0 @@
The configuration for the AMCC 440EP eval board "Bamboo" was changed
to only use 384 kbytes of FLASH for the U-Boot image. This way the
redundant environment can be saved in the remaining 2 sectors of the
same flash chip.
Caution: With an upgrade from an earlier U-Boot version the current
environment will be erased since the environment is now saved in
different sectors. By using the following command the environment can
be saved after upgrading the U-Boot image and *before* resetting the
board:
setenv recover_env 'prot off FFF80000 FFF9FFFF;era FFF80000 FFF9FFFF;' \
'cp.b FFF60000 FFF80000 20000'
2006-07-27, Stefan Roese <sr@denx.de>

88
doc/README.bedbug
View File

@ -1,88 +0,0 @@
BEDBUG Support for U-Boot
--------------------------
These changes implement the bedbug (emBEDded deBUGger) debugger in U-Boot.
A specific implementation is made for the AMCC 405 processor but other flavors
can be easily implemented.
#####################
### Modifications ###
#####################
./common/Makefile
Included cmd_bedbug.c and bedbug.c in the Makefile.
./common/command.c
Added bedbug commands to command table.
./common/board.c
Added call to initialize debugger on startup.
./cpu/ppc4xx/Makefile
Added bedbug_405.c to the Makefile.
./cpu/ppc4xx/start.S
Added code to handle the debug exception (0x2000) on the 405.
Also added code to handle critical exceptions since the debug
is treated as critical on the 405.
./cpu/ppc4xx/traps.c
Added more detailed output for the program exception to tell
if it is an illegal instruction, privileged instruction or
a trap. Also added debug trap handler.
./include/cmd_confdefs.h
Added definition of CFG_CMD_BEDBUG.
./include/config_WALNUT405.h
Added CFG_CMD_BEDBUG to the CONFIG_COMMANDS for the WALNUT.
./include/ppc_asm.tmpl
Added code to handle critical exceptions
#################
### New Stuff ###
#################
./include/bedbug/ppc.h
./include/bedbug/regs.h
./include/bedbug/bedbug.h
./include/bedbug/elf.h [obsoleted by new include/elf.h]
./include/bedbug/tables.h
./include/cmd_bedbug.h
./common/cmd_bedbug.c
./common/bedbug.c
Bedbug library includes code for assembling and disassembling
PowerPC instructions to/from memory as well as handling
hardware breakpoints and stepping through code. These
routines are common to all PowerPC processors.
./cpu/ppc4xx/bedbug_405.c
AMCC PPC405 specific debugger routines.
Bedbug support for the MPC860
-----------------------------
Changes:
common/cmd_bedbug.c
Added call to initialize 860 debugger.
cpu/mpc8xx/Makefile
Added new file "bedbug_860.c" to the makefile
cpu/mpc8xx/start.S
Added handler for InstructionBreakpoint (0xfd00)
cpu/mpc8xx/traps.c
Added new routine DebugException()
include/config_MBX.h
Added CFG_CMD_BEDBUG to CONFIG_COMMANDS define
New Files:
cpu/mpc8xx/bedbug_860.c
CPU-specific routines for 860 debug registers.

84
doc/README.cmi
View File

@ -1,84 +0,0 @@
Summary:
========
This file contains information about the cmi board configuration.
Please see cmi_mpc5xx_config for further details. The cmi board is
a customer specific board but should work with small modifications
on every board which has a MPC5xx and either a 28F128J3A,
28F320J3A or 28F640J3A Intel flash mounted.
Board Discription:
==================
* Motorola MPC555
* RS232 connection
* Intel flash 28F640J3A
* Micron SRAM 1M
* Altera PLD
Bootstrap:
==========
In contrast to the usual boot sequence used in U-Boot, on the
cmi board we don't boot from the external flash directly.
Because of we use a 16-bit flash and don't sample a RCW
from the data bus to set the startup buswidth to 16-bit.
Unfortunatly the default width, sampled from the default RCW
is 32-bit. For this reason we burn the proper RCW into the
internal flash shadow location and boot after power-on or
reset from the internal flash and then branch to 0x02000100
where the U-Boot reset vector handler is located.
Memory Map:
===========
Memory Map after relocation:
0x0000 0000 CFG_SDRAM_BASE
:
0x000F 9FFF
:
:
0x0100 0000 CFG_IMMR (Internal memory map base adress)
:
0x0130 7FFF
:
:
0x0200 0000 CFG_FLASH_BASE
:
0x027C FFFF
:
:
0x0300 0000 PLD_BASE
Flash Partition:
0x0200 0000 Block 0 and 1 contain U-Boot except
: environment
:
0x0201 FFFF
0x0202 0000 Block 2 contains environment (.ppcenv)
:
0x0202 FFFF
See README file for futher information about U-Boot relocation
and partitioning.
Tested Features:
================
* U-Boot commands: go, loads, loadb, all memory features, printenv,
setenv, saveenv, protect, erase, fli, bdi, mtest, reset, version,
coninfo, help (see configuration file for available commands)
* Blinking led to indicate boot process
Added or Changed Files:
=======================
u-boot-0.2.0/board/cmi/*
u-boot-0.2.0/include/configs/cmi_mpc5xx.h
Regards,
Martin

31
doc/README.commands
View File

@ -1,31 +0,0 @@
Commands are added to U-Boot by creating a new command structure.
This is done by first including command.h
Then using the U_BOOT_CMD() macro to fill in a cmd_tbl_t struct.
U_BOOT_CMD(name,maxargs,repeatable,command,"usage","help")
name: is the name of the commad. THIS IS NOT a string.
maxargs: the maximumn numbers of arguments this function takes
command: Function pointer (*cmd)(struct cmd_tbl_s *, int, int, char *[]);
usage: Short description. This is a string
help: long description. This is a string
**** Behinde the scene ******
The structure created is named with a special prefix (__u_boot_cmd_)
and placed by the linker in a special section.
This makes it possible for the final link to extract all commands
compiled into any object code and construct a static array so the
command can be found in an array starting at __u_boot_cmd_start.
If a new board is defined do not forget to define the command section
by writing in u-boot.lds ($(TOPDIR)/board/boardname/u-boot.lds) these
3 lines:
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;

16
doc/README.commands.itest
View File

@ -1,16 +0,0 @@
A slow day today so here is a revised itest command with provisional
support for comparing strings as well :-))
Now table driven to allow the operators
-eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >=
Uses the expected command modifier for integer compares of width 1, 2 or
4 bytes of .b, .w, .l and the new modifer of .s for a string compare.
String comparison is over the length of the shorter, this hopefully
avoids missing terminators when using an indirect pointer.
eg.
if itest.l *40000 == 12345678 then; ....
if itest.w *40000 != 1234 then; ....
if itest.b *40000 >= 12 then; ....
if itest.s *40000 -eq hello then; ....

118
doc/README.console
View File

@ -1,118 +0,0 @@
/*
* (C) Copyright 2000
* Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
U-Boot console handling
========================
HOW THE CONSOLE WORKS?
----------------------
At system startup U-Boot initializes a serial console. When U-Boot
relocates itself to RAM, all console drivers are initialized (they
will register all detected console devices to the system for further
use).
If not defined in the environment, the first input device is assigned
to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
You can use the command "coninfo" to see all registered console
devices and their flags. You can assign a standard file (stdin,
stdout or stderr) to any device you see in that list simply by
assigning its name to the corresponding environment variable. For
example:
setenv stdin wl_kbd <- To use the wireless keyboard
setenv stdout video <- To use the video console
Do a simple "saveenv" to save the console settings in the environment
and get them working on the next startup, too.
HOW CAN I USE STANDARD FILE INTO THE SOURCES?
---------------------------------------------
You can use the following functions to access the console:
* STDOUT:
putc (to put a char to stdout)
puts (to put a string to stdout)
printf (to format and put a string to stdout)
* STDIN:
tstc (to test for the presence of a char in stdin)
getc (to get a char from stdin)
* STDERR:
eputc (to put a char to stderr)
eputs (to put a string to stderr)
eprintf (to format and put a string to stderr)
* FILE (can be 'stdin', 'stdout', 'stderr'):
fputc (like putc but redirected to a file)
fputs (like puts but redirected to a file)
fprintf (like printf but redirected to a file)
ftstc (like tstc but redirected to a file)
fgetc (like getc but redirected to a file)
Remember that all FILE-related functions CANNOT be used before
U-Boot relocation (done in 'board_init_r' in common/board.c).
HOW CAN I USE STANDARD FILE INTO APPLICATIONS?
----------------------------------------------
Use the 'bd_mon_fnc' field of the bd_t structure passed to the
application to do everything you want with the console.
But REMEMBER that that will work only if you have not overwritten any
U-Boot code while loading (or uncompressing) the image of your
application.
For example, you won't get the console stuff running in the Linux
kernel because the kernel overwrites U-Boot before running. Only
some parameters like the framebuffer descriptors are passed to the
kernel in the high memory area to let the applications (the kernel)
use the framebuffers initialized by U-Boot.
SUPPORTED DRIVERS
-----------------
Working drivers:
serial (architecture dependent serial stuff)
video (mpc8xx video controller)
Work in progress:
wl_kbd (Wireless 4PPM keyboard)
Waiting for volounteers:
lcd (mpc8xx lcd controller; to )
TESTED CONFIGURATIONS
---------------------
The driver has been tested with the following configurations (see
CREDITS for other contact informations):
- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
- GENIETV with AD7177 on a PAL TV (YCbYCr) - arsenio@tin.it

105
doc/README.db64360
View File

@ -1,105 +0,0 @@
This file contains status information for the port of the U-Boot to the Marvell Development Board DB64360.
Author: Ronen Shitrit <rshitrit@il.marvell.com>
This U-Boot version is based on the work of Brian Waite and his team from Sky Computers, THANKS A LOT.
Supported CPU Types :
+++++++++++++++++++++
IBM750FX (ver 2.3)
MPC7455 (ver 2.1)
Supported CPU Cache Library:
++++++++++++++++++++++++++++
L1 and L2 only.
CPU Control:
++++++++++++
Marvell optimized CPU control settings:
Big Endian
Enable CPU pipeline
Data and address parity checking
AACK# assert after 2 cycles
U-Boot I/O Interface Support:
+++++++++++++++++++++++++++++
- Serial Interface (UART)
This version of U-Boot supports the SIO U-Boot interface driver, with a PC standard baud rate up to 115200 BPS on the ST16C2552 DUART device located on DB-64360-BP device module.
- Network Interface
This LSP supports the following network devices:
o MV64360 Gigabit Ethernet Controller device
o Intel 82559 PCI NIC device
- PCI Interface
This LSP supports the following capabilities over the Marvell(r) device PCI0/1 units:
o Local PCI configuration header control.
o External PCI configuration header control (for other agents on the bus).
o PCI configuration application. Scans and configures the PCI agents on the bus.
o PCI Internal Arbiter activation and configuration.
Memory Interface Support:
+++++++++++++++++++++++++
- DDR
o DDR auto-detection and configuration. Enables access up to 256 MB, due to the limitations of using only four Base Address Translations (BATs).
o Enable DDR ECC in case both DIMM support ECC, and initialize the entire DDR memory by using the idma.
- Devices
o Initializes the MV64360 device's chip-selects 0-3 to enable access to the boot flash, main flash, real time clock (RTC), and external SRAM.
o JFFS2
JFFS2 is a crash/power down safe file system for disk-less embedded devices.
This version of U-Boot supports scanning a JFFS2 file system on the large flash and loading files from it.
Unsupported Features:
+++++++++++++++++++++
Messaging unit - No support for MV64360 Messaging unit.
Watchdog Timer - No support for MV64360 Watchdog unit.
L3 cache - No support for L3 cache on MPC7455
Dual PCU - No support for Dual CPU
PCI-X was never tested
IDMA driver - No support for MV64360 IDMA unit.
BSP Special Considerations:
+++++++++++++++++++++++++++
- DDR DIMM location: Due to PCI specifications, place the larger DIMM module in the MAIN DIMM slot, in order to have full access from the PCI to the DDR while using both DDR slots.
- DDR DIMM types: Due to architectural and software limitations, the registration, CAS Latency, and ECC of both DIMMS should be identical.
Test Cases:
###########
UART:
+++++
Check that the UART baud rate is configured to 57600 and 115200, and check:
Transmit (to the hyper terminal) and Receive (using the keyboard) using Linux minicom.
Load S-Record file over the UART using Windows HyperTerminal.
Network:
++++++++
Use TFTP application to load a debugged executable and execute it.
Insert Intel PCI NIC 82557 rev 08 to PCI slots 0-3 Check correct detection of the PCI NIC, correct configuration of the NIC BARs , and load files by using tftp through the PCI NIC.
Memory:
+++++++
Test DDR DIMMs on DB-64360-BP. See that Uboot report their correct parameters:
o 128MB DIMM consist of 16 x 64Mbit devices
o 128MB DIMM consist of 09 x 128Mbit devices @ 266MHz.
o 256MB DIMM consist of 16 x 128Mbit devices @ 266MHz.
o 256MB DIMM consist of 09 x 256Mbit devices @ 400MHz.
o 512MB DIMM consist of 16 x 256Mbit devices @ 333MHz.
o 512MB DIMM consist of 18 x 256Mbit devices @ 266MHz.
o GigaB DIMM consist of 36 x 256Mbit devices @ 266MHz registered
For each chip select device perform data access to verify its accessibility.
Create a JFFS2 on the large flash through the Linux holding few files, few dirs and a uImage.
Load the U-Boot and:
use the ls command to check correct scan of the JFFS2 on the large flash.
Use the floads command to copy the uImage from the JFFS2 on the large flash to the DIMM SDRAM, and boot the uImage.
PCI:
++++
1)Insert different PCI cards:
Galileo 64120A rev 10 and 12, Intel Nic 82557 rev 08 and Real Tech NIC 8139 rev10
on different slots (0-3) of the PCI and check:
o Correct detection of the PCI devices.
o Correct address mapping of the PCI devices.
2)Insert Galileo 64120A rev 10 on different slots (0-3) of the PCI and check writing and reading pci configuration register through the U-Boot.
Booting Linux through the U-Boot (use the bootargs of the U-Boot as a bootcmd to the kernal)

105
doc/README.db64460
View File

@ -1,105 +0,0 @@
This file contains status information for the port of the U-Boot to the Marvell Development Board DB64460.
Author: Ronen Shitrit <rshitrit@il.marvell.com>
Supported CPU Types :
+++++++++++++++++++++
IBM750Gx Rev 1.0
MPC7457 Rev 1.1
Supported CPU Cache Library:
++++++++++++++++++++++++++++
L1 and L2 only.
CPU Control:
++++++++++++
Marvell optimized CPU control settings:
Big Endian
Enable CPU pipeline
Data and address parity checking
AACK# assert after 2 cycles
U-Boot I/O Interface Support:
+++++++++++++++++++++++++++++
- Serial Interface (UART)
This version of U-Boot supports the SIO U-Boot interface driver, with a PC standard baud rate up to 115200 BPS on the ST16C2552 DUART device located on DB-64360-BP device module.
- Network Interface
This LSP supports the following network devices:
o MV64360 Gigabit Ethernet Controller device
o Intel 82559 PCI NIC device
- PCI Interface
This LSP supports the following capabilities over the Marvell(r) device PCI0/1 units:
o Local PCI configuration header control.
o External PCI configuration header control (for other agents on the bus).
o PCI configuration application. Scans and configures the PCI agents on the bus.
o PCI Internal Arbiter activation and configuration.
Memory Interface Support:
+++++++++++++++++++++++++
- DDR
o DDR auto-detection and configuration. Enables access up to 256 MB, due to the limitations of using only four Base Address Translations (BATs).
o Enable DDR ECC in case both DIMM support ECC, and initialize the entire DDR memory by using the idma.
- Devices
o Initializes the MV64360 device's chip-selects 0-3 to enable access to the boot flash, main flash, real time clock (RTC), and external SRAM.
o JFFS2
JFFS2 is a crash/power down safe file system for disk-less embedded devices.
This version of U-Boot supports scanning a JFFS2 file system on the large flash and loading files from it.
Unsupported Features:
+++++++++++++++++++++
Messaging unit - No support for MV64360 Messaging unit.
Watchdog Timer - No support for MV64360 Watchdog unit.
L3 cache - No support for L3 cache on MPC7455
Dual PCU - No support for Dual CPU
PCI-X was never tested
IDMA driver - No support for MV64360 IDMA unit.
XOR Engine - No support for MV64460 XOR Engine
BSP Special Considerations:
+++++++++++++++++++++++++++
- DDR DIMM location: Due to PCI specifications, place the larger DIMM module in the MAIN DIMM slot, in order to have full access from the PCI to the DDR while using both DDR slots.
- DDR DIMM types: Due to architectural and software limitations, the registration, CAS Latency, and ECC of both DIMMS should be identical.
Test Cases:
###########
UART:
+++++
Check that the UART baud rate is configured to 57600 and 115200, and check:
Transmit (to the hyper terminal) and Receive (using the keyboard) using Linux minicom.
Load S-Record file over the UART using Windows HyperTerminal.
Network:
++++++++
Use TFTP application to load a debugged executable and execute it.
Insert Intel PCI NIC 82557 rev 08 to PCI slots 0-3 Check correct detection of the PCI NIC, correct configuration of the NIC BARs , and load files by using tftp through the PCI NIC.
Memory:
+++++++
Test DDR DIMMs on DB-64360-BP. See that Uboot report their correct parameters:
o 128MB DIMM consist of 16 x 64Mbit devices
o 128MB DIMM consist of 09 x 128Mbit devices @ 266MHz.
o 256MB DIMM consist of 16 x 128Mbit devices @ 266MHz.
o 256MB DIMM consist of 09 x 256Mbit devices @ 400MHz.
o 512MB DIMM consist of 16 x 256Mbit devices @ 333MHz.
o 512MB DIMM consist of 18 x 256Mbit devices @ 266MHz.
o GigaB DIMM consist of 36 x 256Mbit devices @ 266MHz registered
For each chip select device perform data access to verify its accessibility.
Create a JFFS2 on the large flash through the Linux holding few files, few dirs and a uImage.
Load the U-Boot and:
use the ls command to check correct scan of the JFFS2 on the large flash.
Use the floads command to copy the uImage from the JFFS2 on the large flash to the DIMM SDRAM, and boot the uImage.
PCI:
++++
1)Insert different PCI cards:
Galileo 64120A rev 10 and 12, Intel Nic 82557 rev 08 and Real Tech NIC 8139 rev10
on different slots (0-3) of the PCI and check:
o Correct detection of the PCI devices.
o Correct address mapping of the PCI devices.
2)Insert Galileo 64120A rev 10 on different slots (0-3) of the PCI and check writing and reading pci configuration register through the U-Boot.
Booting Linux through the U-Boot (use the bootargs of the U-Boot as a bootcmd to the kernal)

153
doc/README.dk1c20
View File

@ -1,153 +0,0 @@
Nios Development Kit
Cyclone Editions
Last Update: January 2, 2004
====================================================================
This file contains information regarding U-Boot and the Altera
Nios Development Kit, Cyclone Edition (DK-1C20). For general Nios
information see doc/README.nios.
For those interested in contributing ... see HELP WANTED section
in doc/README.nios.
Contents:
1. Files
2. Memory Organization
3. Examples
4. Programming U-Boot into FLASH with GERMS
5. Active Serial Memory Interface (ASMI) Support
====================================================================
1. Files
=========
board/altera/dk1c20/*
include/configs/DK1C20.h
2. Memory Organization
=======================
-The heap is placed below the monitor (U-Boot code).
-Global data is placed below the heap.
-The stack is placed below global data (&grows down).
3. Examples
============
The hello_world example works fine. The default load address
is 0x0100_0000 (the start of SDRAM).
4. Programming U-Boot into FLASH with GERMS
============================================
The current version of the DK-1C20 port with the default
configuration settings occupies about 81 KBytes of flash.
A minimal configuration occupies less than 60 KByte (asmi
and network support disabled).
To program U-Boot into the DK-1C20 flash using GERMS do the
following:
1. From the command line, download U-Boot using the nios-run:
$ nios-run -r u-boot.srec
This takes about 45 seconds (GERMS is not very speedy here).
After u-boot is downloaded it will be executed. You should
see the following:
U-Boot 1.0.0-pre (Oct 4 2003 - 07:39:24)
CPU: Nios-32 Rev. 3.3 (0x3038)
Reg file size: 256 LO_LIMIT/HI_LIMIT: 2/14
Board: Altera Nios 1C20 Development Kit
In: serial
Out: serial
Err: serial
==>
2. Quit nios-run and start your terminal application (e.g. start
Hyperterminal or minicom).
3. Download the u-boot code to RAM. When using Hyperterminal, do the
following:
a. From the u-boot command prompt start a binary download to SRAM:
==> loadb 800000
b. Download u-boot.bin using kermit.
4. From the U-Boot command prompt, erase flash 0x40000 to 0x5ffff:
==> erase 1:4-5
5. Copy the binary image from SRAM to flash:
==> cp.b 800000 40000 10000
U-Boot will now automatically start when the board is powered on or
reset using the Standard-32 configuration. To start U-Boot with the
Safe-32 configuration, enter the following GERMS command:
+ g 40000
5. Active Serial Memory Interface (ASMI) Support
================================================
ASMI is fully supported in U-Boot. Please note that ASMI is supported
only on Cyclone devices. Do not expect ASMI to work with Stratix or
APEX devices.
************* IMPORTANT *************
===================================================
IN ORDER FOR THE NIOS ASMI TO OPERATE PROPERLY, THE
CYCLONE DEVICE MUST BE CONFIGURED USING JTAG OR ASMI.
There are two techniques you can use to bootstrap the ASMI. The
first is to use the program_epcs utility that is part of Altera's SDK.
But I've found program_epcs to be slow and cumbersome at best.
An undocumented alternative is to use the Quartus device programing
interface:
1. Select "Active Serial" mode.
2. Choose the xxx.pof file. For example, for the standard_32
configuration use the "standard_32.pof" file.
3. Attach your ByteBlaster to J28. Make sure you have the
cable attached properly -- the orientation of J28 is
different than J24 (the JTAG header). On J28, pin 1 is on
the bottom row, left-most pin.
4. Press and hold the "Power-On Reset" switch (SW10). You will
see the green "Loading" and red "Error" LEDs (LED3 and LED4)
in the on state.
5. While holding down the "Power-On Reset" switch, start the
programming sequence. This only takes about 10 seconds.
6. After programming is complete, release the "Power-On Reset"
switch. The Cyclone device should now load its configuration
from the EPCS4 (U59). The green "User" LED (LED 1) should be
blinking if the device was successfully loaded via ASMI.
7. Remove the ByteBlaster cable. The cable must be removed to
allow the Nios ASMI access to the EPCS4 device.
After you have successfully programmed a configuration into the
EPCS4, the ASMI will be used to load the Cyclone configuration
unless the "Force Safe" switch (SW9) is pressed.
NOTE: To maximize the amount of space available for program use,
you can enable configuration compression in Quartus. With compression
enabled, the size of the standard_32 configuration data is
approximately 192 KBytes.
To use the U-Boot ASMI commands, try typing "help asmi" at the
command prompt. The command "asmi info" will show the current
status of the ASMI.

366
doc/README.dk1c20_std32
View File

@ -1,366 +0,0 @@
TODO: specify IDE i/f
specify ASMI i/f
specify OCI
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[6]
CPU: "standard_32"
32 bit NIOS for 50 MHz
256 Byte for register file (15 levels)
4 KByte instruction cache (2 bytes in each cache line)
4 KByte data cache (4 bytes in each cache line)
2 KByte On Chip ROM with GERMS boot monitor
no On Chip RAM
MSTEP multiplier
no Debug Core
On Chip Instrumentation (OCI) enabled
U-Boot CFG: CFG_NIOS_CPU_CLK = 50000000
CFG_NIOS_CPU_ICACHE = 4096
CFG_NIOS_CPU_DCACHE = 4096
CFG_NIOS_CPU_REG_NUMS = 256
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
OCI: (TODO)
IRQ: Nr. | used by
------+--------------------------------------------------------
16 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 16
25 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 25
30 | LAN91C111 | CFG_NIOS_CPU_LAN0_IRQ = 30
35 | PIO5 | CFG_NIOS_CPU_PIO5_IRQ = 35
40 | PIO0 | CFG_NIOS_CPU_PIO0_IRQ = 40
45 | ASMI | CFG_NIOS_CPU_ASMI0_IRQ = 45
50 | TIMER1 | CFG_NIOS_CPU_TIMER1_IRQ = 50
MEMORY: 8 MByte Flash
1 MByte SRAM
16 MByte SDRAM
ASMI: (TODO) <-- ASMI part is 4M bits
Timer: TIMER0: high priority programmable timer (IRQ16)
TIMER1: low priority fixed timer for 10 ms @ 50 MHz (IRQ50)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 1
CFG_NIOS_CPU_USER_TIMER = 0
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | BUTTON: 4 inputs for user push buttons (IRQ40)
PIO1 | LCD: 11 in/outputs for ASCII LCD
PIO2 | LED: 8 outputs for user LEDs
PIO3 | SEVENSEG: 16 outputs for user seven segment display
PIO4 | RECONF: 1 in/output for . . . . . . . . . . . .
PIO5 | CFPRESENT: 1 input for CF present event (IRQ35)
PIO6 | CFPOWER: 1 output to controll CF power supply
PIO7 | CFATASEL: 1 output to controll CF ATA card select
U-Boot CFG: CFG_NIOS_CPU_BUTTON_PIO = 0
CFG_NIOS_CPU_LCD_PIO = 1
CFG_NIOS_CPU_LED_PIO = 2
CFG_NIOS_CPU_SEVENSEG_PIO = 3
CFG_NIOS_CPU_RECONF_PIO = 4
CFG_NIOS_CPU_CFPRESENT_PIO = 5
CFG_NIOS_CPU_CFPOWER_PIO = 6
CFG_NIOS_CPU_CFATASEL_PIO = 7
UART: UART0: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ25)
LAN: SMsC LAN91C111 with:
- offset 0x300 (LAN91C111_REGISTERS_OFFSET)
- data bus width 32 bit (LAN91C111_DATA_BUS_WIDTH)
IDE: (TODO)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external memory 2 - - - - - - - - - - - - - - - - - - -
0x02000000 ---32-----------16|15------------0-
| : | \
| : | |
SDRAM | : | > CFG_NIOS_CPU_SDRAM_SIZE
| : | | = 0x01000000
| : | /
0x01000000 ---32-----------16|15------------0- CFG_NIOS_CPU_SDRAM_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x________ ---32-----------16|15------------0-
| | | \
: (real size : : |
ASMI i/f : and content : : > 0x________
[5] : unknown) : : |
| | | /
0x00920b00 ---32-----------16|15------------0- CFG_NIOS_CPU_ASMI0
| |
: gap :
| |
0x00920a80 ---32-----------16|15------------0-
| | | \
: (real size : : |
IDE i/f : and content : : > 0x00000080
[6] : unknown) : : |
| | | /
0x00920a00 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER1 | (unused) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| (unused) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x009209e0 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER1
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO7 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209d0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO7
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO6 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209c0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO6
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO5 | interruptmask (1 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x009209b0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO5
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO4 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (rw) | /
0x009209a0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO4
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO3 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (16 bit) (wo) | /
0x00920990 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO3
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO2 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (8 bit) (wo) | /
0x00920980 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO2
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (11 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (11 bit) (rw) | /
0x00920970 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| edgecapture (4 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | interruptmask (4 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (4 bit) (ro) | /
0x00920960 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00920940 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| | \
: gap : > (space for UART1)
| | /
0x00920920 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00920900 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip debugging - - - - - - - - - - - - - - - - - - -
0x00920900 -----------------------------------
| | \
: (real size : |
OCI Debug : and content : > CFG_NIOS_CPU_OCI_SIZE
: unknown) : | = 0x00000100
| | /
0x00920800 ----------------------------------- CFG_NIOS_CPU_OCI_BASE
- - - - - - - - - - - on chip memory - - - - - - - - - - -
0x00920800 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > CFG_NIOS_CPU_ROM_SIZE
| : | | = 0x00000800
| : | /
0x00920000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_RST_VECT
0x00920000 ---32-----------16|15------------0- CFG_NIOS_CPU_ROM_BASE
- - - - - - - - - - - external i/o - - - - - - - - - - - - - - - - - - -
0x00920000 ---32-----------16|15------------0-
| gap | \
0x00910310 --+-------------------------------| |
| | |
| register bank (size = 0x10) | |
| +--------.---.---.--- | |
| | bank 0 \ 1 \ 2 \ 3 \ | |
| |---------------------------+ | |
LAN91C111 | | BANK | RESERVED | | |
| |- - - - - - -|- - - - - - -| | > na_lan91c111_size
| | RPCR | MIR | | | = 0x00010000
| |- - - - - - -|- - - - - - -| | |
| | COUNTER | RCR | | |
| |- - - - - - -|- - - - - - -| | |
| | EPH STATUS | TCR | | |
| +---------------------------+ | |
0x00910300 --+--LAN91C111_REGISTERS_OFFSET---| |
| gap | /
0x00910000 ---32-----------16|15------------0- CFG_NIOS_CPU_LAN0_BASE
| |
: gap :
: :
- - - - - - - - - - - external memory 1 - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00900000 ---32-----------16|15------------0-
0x00900000 --+32-----------16|15------------0+
| : | \ \
| : | | |
| : | | > CFG_NIOS_CPU_VEC_SIZE
| : | | | = 0x00000100
| : | | /
0x008fff00 |- - - - - - - -:- - - - - - - -+-|- CFG_NIOS_CPU_VEC_BASE
0x008fff00 |- - - - - - - -:- - - - - - - -+-|- CFG_NIOS_CPU_STACK
| : | | \
| : | | |
| : | | > stack area
| : | | |
| : | | V
| : | |
SRAM | : | > CFG_NIOS_CPU_SRAM_SIZE
| : | | = 0x00100000
| : | /
0x00800000 ---32-----------16|15------------0- CFG_NIOS_CPU_SRAM_BASE
0x00800000 ---8-------------4|3-------------0-
| sector 127 | \
+ 0x7f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 1 : | | = 0x00800000
+ 0x010000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x10000) | /
0x00000000 ---8-------------4|3-------------0- CFG_NIOS_CPU_FLASH_BASE
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x00800000 ---8-------------4|3-------------0-
| : | \
SAFE | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00700000 --+- - - - - - - -:- - - - - - - -+-
| : | \
USER | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00600000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
WEB pages | : | > 2 MByte
| : | | (provisory usable)
| : | /
0x00400000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
| : | |
| : | > 4 MByte free for use
| : | |
0x00040000 --+- - - - - - - -:- - - - - - - -+-|- u-boot _start()
| : | /
0x00000000 |- - - - - - - -:- - - - - - - -+- - u-boot environment
0x00000000 ---8-------------4|3-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/manual/mnl_nios_board_cyclone_1c20.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[5] http://www.altera.com/literature/ds/ds_nios_asmi.pdf
http://www.altera.com/literature/wp/wp_epcs_cyc.pdf
[6] http://www.opencores.org/projects/ata/
http://www.t13.org/index.html
===============================================================================
Stephan Linz <linz@li-pro.net>

131
doc/README.dk1s10
View File

@ -1,131 +0,0 @@
Nios Development Kit
Startix Editions
Last Update: January 28, 2004
====================================================================
This file contains information regarding U-Boot and the Altera
Nios Development Kit, Startix Edition (DK-1S10). For general Nios
information see doc/README.nios.
Most stuff of this file was borrowed and based on README.dk1c20,
the DK-1C20 related information file.
For those interested in contributing ... see HELP WANTED section
in doc/README.nios.
Contents:
1. Files
2. Memory Organization
3. CPU Variations
4. Examples
5. Programming U-Boot into FLASH with GERMS
====================================================================
1. Files
=========
board/altera/dk1s10/*
include/configs/DK1S10.h
2. Memory Organization
=======================
-The heap is placed below the monitor (U-Boot code).
-Global data is placed below the heap.
-The stack is placed below global data (&grows down).
3. CPU Variations
=================
There are more than one NIOS CPU variation for the DK-1S10. U-Boot
supports the following CPU configurations:
- Altera Standard 32 (make DK1S10_standard_32_config)
- Microtronix LDK 2.0 (make DK1S10_mtx_ldk_20_config)
4. Examples
============
The hello_world example was never tested on DK-1S10. Neverthelse
it should work as far as possible, because the DK-1S10 port is
more than ninetieth percents equal to the DK-1C20 port and at
this platform the hello_world example was already tested
successfully (see README.dk1c20).
5. Programming U-Boot into FLASH with GERMS
============================================
The current version of the DK-1S10 port with the default
configuration settings occupies about 78 KBytes of flash.
A minimal configuration occupies less than 60 KByte
(network support disabled).
To program U-Boot into the DK-1S10 flash using GERMS do the
following:
1. From the command line, download U-Boot using the nios-run:
$ nios-run -r u-boot.srec
This takes about 45 seconds (GERMS is not very speedy here).
After u-boot is downloaded it will be executed. You should
see the following:
U-Boot 1.0.2 (Jan 28 2004 - 19:02:30)
CPU: Nios-32 Rev. 3.3 (0x3038)
Reg file size: 256 LO_LIMIT/HI_LIMIT: 2/14
Board: Altera Nios 1S10 Development Kit
In: serial
Out: serial
Err: serial
DK1S10 >
2. Quit nios-run and start your terminal application (e.g. start
Hyperterminal or minicom).
3. Download the u-boot code to RAM. When using Hyperterminal, do the
following:
a. From the u-boot command prompt start a binary download to
SRAM / SDRAM:
at the Altera Standard 32 to SRAM:
==> loadb 800000
at the Microtronix LDK 2.0 to SDRAM:
==> loadb 1010000
b. Download u-boot.bin using kermit.
4. From the U-Boot command prompt, erase flash:
at the Altera Standard 32 from 0x40000 to 0x5ffff:
==> erase 1:4-5
at the Microtronix LDK 2.0 from 0x8000000 to 0x81ffff:
==> erase 1:0-1
5. Copy the binary image from SRAM / SDRAM to flash:
at the Altera Standard 32 to SRAM:
==> cp.b 800000 40000 ${filesize}
at the Microtronix LDK 2.0 to SDRAM:
==> cp.b 1010000 8000000 ${filesize}
U-Boot will now automatically start when the board is powered on or
reset using the Standard-32 configuration. To start U-Boot with the
Safe-32 configuration, enter the following GERMS command:
+ g 40000

286
doc/README.dk1s10_mldk20
View File

@ -1,286 +0,0 @@
TODO: specify IDE i/f
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[5]
CPU: "LDK2"
32 bit NIOS for 75 MHz
512 Byte for register file (30 levels)
with out instruction cache
with out data cache
2 KByte On Chip ROM with GERMS boot monitor
with out On Chip RAM
MSTEP multiplier
no Debug Core
no On Chip Instrumentation (OCI)
U-Boot CFG: CFG_NIOS_CPU_CLK = 75000000
CFG_NIOS_CPU_ICACHE = (not present)
CFG_NIOS_CPU_DCACHE = (not present)
CFG_NIOS_CPU_REG_NUMS = 512
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
IRQ: Nr. | used by
------+--------------------------------------------------------
16 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 16
17 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 17
18 | UART1 | CFG_NIOS_CPU_UART1_IRQ = 18
20 | LAN91C111 | CFG_NIOS_CPU_LAN0_IRQ = 20
25 | IDE0 | CFG_NIOS_CPU_IDE0_IRQ = 25
MEMORY: 8 MByte Flash
16 MByte SDRAM
Timer: TIMER0: high priority programmable timer (IRQ16)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 0
CFG_NIOS_CPU_USER_TIMER = (not present)
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | CFPOWER: 1 output to controll CF power supply
PIO1 | BUTTON: 4 inputs for user push buttons (no IRQ)
------+--------------------------------------------------------
not | LCD: 11 in/outputs for ASCII LCD
pres.| LED: 8 outputs for user LEDs
| SEVENSEG: 16 outputs for user seven segment display
| RECONF: 1 in/output for . . . . . . . . . . . .
| CFPRESENT: 1 input for CF present event (IRQ35)
| CFATASEL: 1 output to controll CF ATA card select
U-Boot CFG: CFG_NIOS_CPU_BUTTON_PIO = 1
CFG_NIOS_CPU_LCD_PIO = (not present)
CFG_NIOS_CPU_LED_PIO = (not present)
CFG_NIOS_CPU_SEVENSEG_PIO = (not present)
CFG_NIOS_CPU_RECONF_PIO = (not present)
CFG_NIOS_CPU_CFPRESENT_PIO = (not present)
CFG_NIOS_CPU_CFPOWER_PIO = 0
CFG_NIOS_CPU_CFATASEL_PIO = (not present)
UART: UART0: fixed baudrate of 115200, fixed protocol 8N2,
without handshake RTS/CTS (IRQ17)
UART1: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ18)
LAN: SMsC LAN91C111 with:
- offset 0x300 (LAN91C111_REGISTERS_OFFSET)
- data bus width 32 bit (LAN91C111_DATA_BUS_WIDTH)
IDE: (TODO)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external memory - - - - - - - - - - - - - - - - - - -
0x02000000 ---32-----------16|15------------0- CFG_NIOS_CPU_STACK
0x02000000 --+32-----------16|15------------0+
| . | \ \
| . | | |
| . | | > stack area
| . | | |
| . | | V
| . | |
| . | |
SDRAM | . | > CFG_NIOS_CPU_SDRAM_SIZE
| . | | = 0x01000000
| . | |
0x01000100 |- - - - - - - - - - - - - - - -+-|-
| . | | \
| . | | |
| . | | > CFG_NIOS_CPU_VEC_SIZE
| . | | | = 0x00000100
| | / /
0x01000000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_VEC_BASE
0x01000000 ---32-----------16|15------------0- CFG_NIOS_CPU_SDRAM_BASE
| sector 127 | \
+ 0x7f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 1 : | | = 0x00800000
+ 0x010000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x10000) | /
0x00800000 ---8-------------4|3-------------0- CFG_NIOS_CPU_FLASH_BASE
| |
: gap :
: :
- - - - - - - - - - - external i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00020000 ---32-----------16|15------------0-
| gap | \
0x00010310 --+-------------------------------| |
| | |
| register bank (size = 0x10) | |
| +--------.---.---.--- | |
| | bank 0 \ 1 \ 2 \ 3 \ | |
| |---------------------------+ | |
LAN91C111 | | BANK | RESERVED | | |
| |- - - - - - -|- - - - - - -| | > na_enet_size
| | RPCR | MIR | | | = 0x00010000
| |- - - - - - -|- - - - - - -| | |
| | COUNTER | RCR | | |
| |- - - - - - -|- - - - - - -| | |
| | EPH STATUS | TCR | | |
| +---------------------------+ | |
0x00010300 --+--LAN91C111_REGISTERS_OFFSET---| |
| gap | /
0x00010000 ---32-----------16|15------------0- CFG_NIOS_CPU_LAN0_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00000980 ---32-----------16|15------------0-
| | | \
: (real size : : |
IDE i/f : and content : : > 0x00000080
[5] : unknown) : : |
| | | /
0x00000900 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE0
| | \
: gap : > (space for PIO4..7)
| | /
0x000008c0 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART1 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x000008a0 ---32-----------16|15------------0- CFG_NIOS_CPU_UART1
| | \
: gap : > (space for PIO2..3)
| | /
0x00000880 ---32-----------16|15------------0-
| edgecapture (4 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | interruptmask (4 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (4 bit) (ro) | /
0x00000870 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x00000860 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00000840 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| | \
: gap : > (space for UART2)
| | /
0x00000820 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00000800 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip memory 1 - - - - - - - - - - -
0x00000800 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > CFG_NIOS_CPU_ROM_SIZE
| : | | = 0x00000800
| : | /
0x00000000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_RST_VECT
0x00000000 ---32-----------16|15------------0- CFG_NIOS_CPU_ROM_BASE
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x01000000 ---8-------------4|3-------------0-
| : | \
SAFE | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00f00000 --+- - - - - - - -:- - - - - - - -+-
| : | \
USER | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00e00000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
WEB pages | : | > 2 MByte
| : | | (provisory usable)
| : | /
0x00c00000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
| : | |
| : | > 4 MByte free for use
| : | |
0x00840000 --+- - - - - - - -:- - - - - - - -+-|- u-boot environment
| : | /
0x00800000 |- - - - - - - -:- - - - - - - -+- - u-boot _start()
0x00800000 ---8-------------4|3-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/manual/mnl_nios_board_stratix_1s10.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[5] http://www.opencores.org/projects/ata/
http://www.t13.org/index.html
===============================================================================
Stephan Linz <linz@li-pro.net>

354
doc/README.dk1s10_std32
View File

@ -1,354 +0,0 @@
TODO: specify IDE i/f
specify OCI
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[5]
CPU: "standard_32"
32 bit NIOS for 50 MHz
256 Byte for register file (15 levels)
4 KByte instruction cache (4 bytes in each cache line)
4 KByte data cache (4 bytes in each cache line)
2 KByte On Chip ROM with GERMS boot monitor
64 KByte On Chip RAM
MSTEP multiplier
no Debug Core
On Chip Instrumentation (OCI) enabled
U-Boot CFG: CFG_NIOS_CPU_CLK = 50000000
CFG_NIOS_CPU_ICACHE = 4096
CFG_NIOS_CPU_DCACHE = 4096
CFG_NIOS_CPU_REG_NUMS = 256
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
OCI: (TODO)
IRQ: Nr. | used by
------+--------------------------------------------------------
16 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 16
25 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 25
30 | LAN91C111 | CFG_NIOS_CPU_LAN0_IRQ = 30
35 | PIO5 | CFG_NIOS_CPU_PIO5_IRQ = 35
40 | PIO0 | CFG_NIOS_CPU_PIO0_IRQ = 40
50 | TIMER1 | CFG_NIOS_CPU_TIMER1_IRQ = 50
MEMORY: 8 MByte Flash
1 MByte SRAM
16 MByte SDRAM
Timer: TIMER0: high priority programmable timer (IRQ16)
TIMER1: low priority fixed timer for 10 ms @ 50 MHz (IRQ50)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 1
CFG_NIOS_CPU_USER_TIMER = 0
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | BUTTON: 4 inputs for user push buttons (IRQ40)
PIO1 | LCD: 11 in/outputs for ASCII LCD
PIO2 | LED: 8 outputs for user LEDs
PIO3 | SEVENSEG: 16 outputs for user seven segment display
PIO4 | RECONF: 1 in/output for . . . . . . . . . . . .
PIO5 | CFPRESENT: 1 input for CF present event (IRQ35)
PIO6 | CFPOWER: 1 output to controll CF power supply
PIO7 | CFATASEL: 1 output to controll CF ATA card select
U-Boot CFG: CFG_NIOS_CPU_BUTTON_PIO = 0
CFG_NIOS_CPU_LCD_PIO = 1
CFG_NIOS_CPU_LED_PIO = 2
CFG_NIOS_CPU_SEVENSEG_PIO = 3
CFG_NIOS_CPU_RECONF_PIO = 4
CFG_NIOS_CPU_CFPRESENT_PIO = 5
CFG_NIOS_CPU_CFPOWER_PIO = 6
CFG_NIOS_CPU_CFATASEL_PIO = 7
UART: UART0: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ25)
LAN: SMsC LAN91C111 with:
- offset 0x300 (LAN91C111_REGISTERS_OFFSET)
- data bus width 32 bit (LAN91C111_DATA_BUS_WIDTH)
IDE: (TODO)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external memory 2 - - - - - - - - - - - - - - - - - - -
0x02000000 ---32-----------16|15------------0-
| : | \
| : | |
SDRAM | : | > CFG_NIOS_CPU_SDRAM_SIZE
| : | | = 0x01000000
| : | /
0x01000000 ---32-----------16|15------------0- CFG_NIOS_CPU_SDRAM_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00920a80 ---32-----------16|15------------0-
| | | \
: (real size : : |
IDE i/f : and content : : > 0x00000080
[5] : unknown) : : |
| | | /
0x00920a00 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER1 | (unused) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| (unused) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x009209e0 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER1
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO7 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209d0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO7
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO6 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209c0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO6
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO5 | interruptmask (1 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x009209b0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO5
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO4 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (rw) | /
0x009209a0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO4
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO3 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (16 bit) (wo) | /
0x00920990 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO3
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO2 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (8 bit) (wo) | /
0x00920980 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO2
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (11 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (11 bit) (rw) | /
0x00920970 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| edgecapture (4 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | interruptmask (4 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (4 bit) (ro) | /
0x00920960 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00920940 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| | \
: gap : > (space for UART1)
| | /
0x00920920 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00920900 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip debugging - - - - - - - - - - - - - - - - - - -
0x00920900 -----------------------------------
| | \
: (real size : |
OCI Debug : and content : > CFG_NIOS_CPU_OCI_SIZE
: unknown) : | = 0x00000100
| | /
0x00920800 ----------------------------------- CFG_NIOS_CPU_OCI_BASE
- - - - - - - - - - - on chip memory 2 - - - - - - - - - - -
0x00920800 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > CFG_NIOS_CPU_ROM_SIZE
| : | | = 0x00000800
| : | /
0x00920000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_RST_VECT
0x00920000 ---32-----------16|15------------0- CFG_NIOS_CPU_ROM_BASE
- - - - - - - - - - - external i/o - - - - - - - - - - - - - - - - - - -
0x00920000 ---32-----------16|15------------0-
| gap | \
0x00910310 --+-------------------------------| |
| | |
| register bank (size = 0x10) | |
| +--------.---.---.--- | |
| | bank 0 \ 1 \ 2 \ 3 \ | |
| |---------------------------+ | |
LAN91C111 | | BANK | RESERVED | | |
| |- - - - - - -|- - - - - - -| | > na_lan91c111_size
| | RPCR | MIR | | | = 0x00010000
| |- - - - - - -|- - - - - - -| | |
| | COUNTER | RCR | | |
| |- - - - - - -|- - - - - - -| | |
| | EPH STATUS | TCR | | |
| +---------------------------+ | |
0x00910300 --+--LAN91C111_REGISTERS_OFFSET---| |
| gap | /
0x00910000 ---32-----------16|15------------0- CFG_NIOS_CPU_LAN0_BASE
- - - - - - - - - - - on chip memory 1 - - - - - - - - - - -
0x00910000 ---32-----------16|15------------0-
| : | \
| : | |
onchip RAM | : | > CFG_NIOS_CPU_RAM_SIZE
| : | | = 0x00010000
| : | /
0x00900000 ---32-----------16|15------------0- CFG_NIOS_CPU_RAM_BASE
- - - - - - - - - - - external memory 1 - - - - - - - - - - - - - - - - - - -
0x00900000 ---32-----------16|15------------0-
0x00900000 --+32-----------16|15------------0+
| . | \ \
| . | | |
| . | | > CFG_NIOS_CPU_VEC_SIZE
| . | | | = 0x00000100
| . | | /
0x008fff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_VEC_BASE
0x008fff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_STACK
| . | | \
| . | | |
| . | | > stack area
| . | | |
| . | | V
| . | |
SRAM | . | > CFG_NIOS_CPU_SRAM_SIZE
| . | | = 0x00100000
| | /
0x00800000 ---32-----------16|15------------0- CFG_NIOS_CPU_SRAM_BASE
0x00800000 ---8-------------4|3-------------0-
| sector 127 | \
+ 0x7f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 1 : | | = 0x00800000
+ 0x010000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x10000) | /
0x00000000 ---8-------------4|3-------------0- CFG_NIOS_CPU_FLASH_BASE
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x00800000 ---8-------------4|3-------------0-
| : | \
SAFE | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00700000 --+- - - - - - - -:- - - - - - - -+-
| : | \
USER | : | > 1 MByte
FPGA conf. | : | / (NOT usable by software)
0x00600000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
WEB pages | : | > 2 MByte
| : | | (provisory usable)
| : | /
0x00400000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
| : | |
| : | > 4 MByte free for use
| : | |
0x00040000 --+- - - - - - - -:- - - - - - - -+-|- u-boot _start()
| : | /
0x00000000 |- - - - - - - -:- - - - - - - -+- - u-boot environment
0x00000000 ---8-------------4|3-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/manual/mnl_nios_board_stratix_1s10.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[5] http://www.opencores.org/projects/ata/
http://www.t13.org/index.html
===============================================================================
Stephan Linz <linz@li-pro.net>

355
doc/README.dk1s40_std32
View File

@ -1,355 +0,0 @@
TODO: specify IDE i/f
specify OCI
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[5]
CPU: "standard_32"
32 bit NIOS for 50 MHz
256 Byte for register file (15 levels)
4 KByte instruction cache (4 bytes in each cache line)
4 KByte data cache (4 bytes in each cache line)
2 KByte On Chip ROM with GERMS boot monitor
64 KByte On Chip RAM
MSTEP multiplier
no Debug Core
On Chip Instrumentation (OCI) enabled
U-Boot CFG: CFG_NIOS_CPU_CLK = 50000000
CFG_NIOS_CPU_ICACHE = 4096
CFG_NIOS_CPU_DCACHE = 4096
CFG_NIOS_CPU_REG_NUMS = 256
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
OCI: (TODO)
IRQ: Nr. | used by
------+--------------------------------------------------------
16 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 16
25 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 25
30 | LAN91C111 | CFG_NIOS_CPU_LAN0_IRQ = 30
35 | PIO5 | CFG_NIOS_CPU_PIO5_IRQ = 35
40 | PIO0 | CFG_NIOS_CPU_PIO0_IRQ = 40
50 | TIMER1 | CFG_NIOS_CPU_TIMER1_IRQ = 50
MEMORY: 8 MByte Flash
1 MByte SRAM
16 MByte SDRAM
Timer: TIMER0: high priority programmable timer (IRQ16)
TIMER1: low priority fixed timer for 10 ms @ 50 MHz (IRQ50)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 1
CFG_NIOS_CPU_USER_TIMER = 0
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | BUTTON: 4 inputs for user push buttons (IRQ40)
PIO1 | LCD: 11 in/outputs for ASCII LCD
PIO2 | LED: 8 outputs for user LEDs
PIO3 | SEVENSEG: 16 outputs for user seven segment display
PIO4 | RECONF: 1 in/output for . . . . . . . . . . . .
PIO5 | CFPRESENT: 1 input for CF present event (IRQ35)
PIO6 | CFPOWER: 1 output to controll CF power supply
PIO7 | CFATASEL: 1 output to controll CF ATA card select
U-Boot CFG: CFG_NIOS_CPU_BUTTON_PIO = 0
CFG_NIOS_CPU_LCD_PIO = 1
CFG_NIOS_CPU_LED_PIO = 2
CFG_NIOS_CPU_SEVENSEG_PIO = 3
CFG_NIOS_CPU_RECONF_PIO = 4
CFG_NIOS_CPU_CFPRESENT_PIO = 5
CFG_NIOS_CPU_CFPOWER_PIO = 6
CFG_NIOS_CPU_CFATASEL_PIO = 7
UART: UART0: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ25)
LAN: SMsC LAN91C111 with:
- offset 0x300 (LAN91C111_REGISTERS_OFFSET)
- data bus width 32 bit (LAN91C111_DATA_BUS_WIDTH)
IDE: (TODO)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external memory 2 - - - - - - - - - - - - - - - - - - -
0x02000000 ---32-----------16|15------------0-
| : | \
| : | |
SDRAM | : | > CFG_NIOS_CPU_SRAM_SIZE
| : | | = 0x01000000
| : | /
0x01000000 ---32-----------16|15------------0- CFG_NIOS_CPU_SRAM_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00920a80 ---32-----------16|15------------0-
| | | \
: (real size : : |
IDE i/f : and content : : > 0x00000080
[5] : unknown) : : |
| | | /
0x00920a00 ---32-----------16|15------------0- CFG_NIOS_CPU_IDE0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER1 | (unused) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| (unused) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x009209e0 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER1
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO7 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209d0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO7
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO6 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (wo) | /
0x009209c0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO6
| edgecapture (1 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO5 | interruptmask (1 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (ro) | /
0x009209b0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO5
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO4 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (1 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (1 bit) (rw) | /
0x009209a0 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO4
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO3 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (16 bit) (wo) | /
0x00920990 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO3
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO2 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (8 bit) (wo) | /
0x00920980 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO2
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (11 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (11 bit) (rw) | /
0x00920970 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| edgecapture (4 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | interruptmask (4 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (4 bit) (ro) | /
0x00920960 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00920940 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| | \
: gap : > (space for UART1)
| | /
0x00920920 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00920900 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip debugging - - - - - - - - - - - - - - - - - - -
0x00920900 -----------------------------------
| | \
: (real size : |
OCI Debug : and content : > CFG_NIOS_CPU_OCI_SIZE
: unknown) : | = 0x00000100
| | /
0x00920800 ----------------------------------- CFG_NIOS_CPU_OCI_BASE
- - - - - - - - - - - on chip memory 2 - - - - - - - - - - -
0x00920800 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > CFG_NIOS_CPU_ROM_SIZE
| : | | = 0x00000800
| : | /
0x00920000 |- - - - - - - - - - - - - - - -+- - CFG_NIOS_CPU_RST_VECT
0x00920000 ---32-----------16|15------------0- CFG_NIOS_CPU_ROM_BASE
- - - - - - - - - - - external i/o - - - - - - - - - - - - - - - - - - -
0x00920000 ---32-----------16|15------------0-
| gap | \
0x00910310 --+-------------------------------| |
| | |
| register bank (size = 0x10) | |
| +--------.---.---.--- | |
| | bank 0 \ 1 \ 2 \ 3 \ | |
| |---------------------------+ | |
LAN91C111 | | BANK | RESERVED | | |
| |- - - - - - -|- - - - - - -| | > na_lan91c111_size
| | RPCR | MIR | | | = 0x00010000
| |- - - - - - -|- - - - - - -| | |
| | COUNTER | RCR | | |
| |- - - - - - -|- - - - - - -| | |
| | EPH STATUS | TCR | | |
| +---------------------------+ | |
0x00910300 --+--LAN91C111_REGISTERS_OFFSET---| |
| gap | /
0x00910000 ---32-----------16|15------------0- CFG_NIOS_CPU_LAN0_BASE
- - - - - - - - - - - on chip memory 1 - - - - - - - - - - -
0x00910000 ---32-----------16|15------------0-
| : | \
| : | |
onchip RAM | : | > CFG_NIOS_CPU_RAM_SIZE
| : | | = 0x00010000
| : | /
0x00900000 ---32-----------16|15------------0- CFG_NIOS_CPU_RAM_BASE
- - - - - - - - - - - external memory 1 - - - - - - - - - - - - - - - - - - -
0x00900000 ---32-----------16|15------------0-
0x00900000 --+32-----------16|15------------0+
| . | \ \
| . | | |
| . | | > CFG_NIOS_CPU_VEC_SIZE
| . | | | = 0x00000100
| . | | /
0x008fff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_VEC_BASE
0x008fff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_STACK
| . | | \
| . | | |
| . | | > stack area
| . | | |
| . | | V
| . | |
SRAM | . | > CFG_NIOS_CPU_SRAM_SIZE
| . | | = 0x00100000
| | /
0x00800000 ---32-----------16|15------------0- CFG_NIOS_CPU_SRAM_BASE
0x00800000 ---8-------------4|3-------------0-
| sector 127 | \
+ 0x7f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 1 : | | = 0x00800000
+ 0x010000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x10000) | /
0x00000000 ---8-------------4|3-------------0- CFG_NIOS_CPU_FLASH_BASE
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x00800000 ---8-------------4|3-------------0-
| : | \
| : | |
SAFE | : | > 2 MByte
FPGA conf. | : | | (NOT usable by software)
| : | /
0x00600000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
USER | : | > 2 MByte
FPGA conf. | : | | (NOT usable by software)
| : | /
0x00400000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
WEB pages | : | > 2 MByte
| : | | (provisory usable)
| : | /
0x00200000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
| : | > 2 MByte free for use
0x00040000 --+- - - - - - - -:- - - - - - - -+-|- u-boot _start()
| : | /
0x00000000 ---8-------------4|3-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/manual/mnl_nios_board_stratix_1s40.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[5] http://www.opencores.org/projects/ata/
http://www.t13.org/index.html
===============================================================================
Stephan Linz <linz@li-pro.net>

242
doc/README.dk20k200_std32
View File

@ -1,242 +0,0 @@
===============================================================================
C P U , M E M O R Y , I N / O U T C O M P O N E N T S
===============================================================================
see also [1]-[4]
CPU: "standard_32"
32 bit NIOS for 33.333 MHz (nasys_clock_freq = 33333000)
256 Byte for register file (15 levels)
no instruction cache
no data cache
1 KByte On Chip ROM with GERMS boot monitor
no On Chip RAM
MSTEP multiplier
no Debug Core
no On Chip Instrumentation (OCI) enabled
U-Boot CFG: CFG_NIOS_CPU_CLK = 50000000
CFG_NIOS_CPU_ICACHE = 0
CFG_NIOS_CPU_DCACHE = 0
CFG_NIOS_CPU_REG_NUMS = 256
CFG_NIOS_CPU_MUL = 0
CFG_NIOS_CPU_MSTEP = 1
CFG_NIOS_CPU_DBG_CORE = 0
IRQ: Nr. | used by
------+--------------------------------------------------------
25 | TIMER0 | CFG_NIOS_CPU_TIMER0_IRQ = 25
26 | UART0 | CFG_NIOS_CPU_UART0_IRQ = 26
27 | PIO2 | CFG_NIOS_CPU_PIO2_IRQ = 27
28 | UART1 | CFG_NIOS_CPU_UART1_IRQ = 28 (debug)
MEMORY: 1 MByte Flash
256 KByte SRAM
(SDRAM with standard SODIMM only)
Timer: TIMER0: high priority programmable timer (IRQ25)
U-Boot CFG: CFG_NIOS_CPU_TICK_TIMER = 0
PIO: Nr. | description
------+--------------------------------------------------------
PIO0 | SEVENSEG: 16 outputs for user seven segment display
PIO1 | LED: 8 outputs for user LEDs
PIO2 | BUTTON: 4 inputs for user push buttons (IRQ27)
PIO3 | LCD: 11 in/outputs for ASCII LCD
U-Boot CFG: CFG_NIOS_CPU_SEVENSEG_PIO = 0
CFG_NIOS_CPU_LED_PIO = 1
CFG_NIOS_CPU_BUTTON_PIO = 2
CFG_NIOS_CPU_LCD_PIO = 3
UART: UART0: fixed baudrate of 115200, fixed protocol 8N2,
without handshake RTS/CTS (IRQ26)
UART1: fixed baudrate of 115200, fixed protocol 8N1,
without handshake RTS/CTS (IRQ28)
===============================================================================
M E M O R Y M A P
===============================================================================
- - - - - - - - - - - external memory - - - - - - - - - - - - - - - - - - -
0x00200000 ---15------------8|7-------------0-
| sector 18 | \
+ 0x0f0000 |- - - - - - - - - - - - - - - -| |
| : | |
Flash |- - - - : - - - -| |
| sector 5 : | |
+ 0x020000 |- - - - - - - - -| |
| sector 4 (size = 0x10000) | |
+ 0x010000 |- - - - - - - - - - - - - - - -| > CFG_NIOS_CPU_FLASH_SIZE
| sector 3 (size = 0x08000) | | = 0x00100000
+ 0x008000 |- - - - - - - - - - - - - - - -| |
| sector 2 (size = 0x02000) | |
+ 0x006000 |- - - - - - - - - - - - - - - -| |
| sector 1 (size = 0x02000) | |
+ 0x004000 |- - - - - - - - - - - - - - - -| |
| sector 0 (size = 0x04000) | /
0x00100000 ---15------------8|7-------------0- CFG_NIOS_CPU_FLASH_BASE
| |
: gap :
| |
0x00080000 ---32-----------16|15------------0-
0x00080000 --+32-----------16|15------------0+
| . | \ \
| . | | |
| . | | > CFG_NIOS_CPU_VEC_SIZE
| . | | | = 0x00000100
| . | | /
0x0007ff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_VEC_BASE
0x0007ff00 |- - - - - - - - - - - - - - - -+-|- CFG_NIOS_CPU_STACK
| . | | \
| . | | |
| . | | > stack area
| . | | |
| . | | V
| . | |
SRAM | . | > CFG_NIOS_CPU_SRAM_SIZE
| . | | = 0x00040000
| | /
0x00040000 ---32-----------16|15------------0- CFG_NIOS_CPU_SRAM_BASE
| |
: gap :
: :
- - - - - - - - - - - on chip i/o - - - - - - - - - - - - - - - - - - -
: :
: gap :
| |
0x00000400 ---32-----------16|15------------0-
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART1 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x000004c0 ---32-----------16|15------------0- CFG_NIOS_CPU_UART1
| |
: gap :
| |
0x00000490 ---32-----------16|15------------0-
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO3 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (11 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (11 bit) (rw) | /
0x00000480 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO3
| edgecapture (12 bit) (rw) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO2 | interruptmask (12 bit) (rw) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (12 bit) (ro) | /
0x00000470 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO2
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO1 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| direction (2 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (2 bit) (rw) | /
0x00000460 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO1
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| snaph (16 bit) (rw) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
TIMER0 | snapl (16 bit) (rw) | |
[3] + 0x10 |- - - - - - - - - - - - - - - -| > 0x00000020
| periodh (16 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| periodl (16 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| control (4 bit) (rw) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| status (2 bit) (rw) | /
0x00000440 ---32-----------16|15------------0- CFG_NIOS_CPU_TIMER0
| (unused) | \
+ 0x0c |- - - - - - - - - - - - - - - -| |
PIO0 | (unused) | |
[4] + 0x08 |- - - - - - - - - - - - - - - -| > 0x00000010
| (unused) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| data (16 bit) (wo) | /
0x00000420 ---32-----------16|15------------0- CFG_NIOS_CPU_PIO0
| (unused) | \
+ 0x1c |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x18 |- - - - - - - - - - - - - - - -| |
| (unused) | |
+ 0x14 |- - - - - - - - - - - - - - - -| |
UART0 | (unused) | > 0x00000020
[2] + 0x10 |- - - - - - - - - - - - - - - -| |
| control (10 bit) (rw) | |
+ 0x0c |- - - - - - - - - - - - - - - -| |
| status (10 bit) (rw) | |
+ 0x08 |- - - - - - - - - - - - - - - -| |
| txdata (8 bit) (wo) | |
+ 0x04 |- - - - - - - - - - - - - - - -| |
| rxdata (8 bit) (ro) | /
0x00000400 ---32-----------16|15------------0- CFG_NIOS_CPU_UART0
- - - - - - - - - - - on chip memory - - - - - - - - - - -
0x00000400 ---32-----------16|15------------0-
| : | \
| : | |
GERMS | : | > na_boot_monitor_rom_size
| : | | = 0x00000400
| : | /
0x00000000 |- - - - - - - - - - - - - - - -+- - nasys_reset_address
0x00000000 ---32-----------16|15------------0- na_boot_monitor_rom
===============================================================================
F L A S H M E M O R Y A L L O C A T I O N
===============================================================================
0x00200000 ---15------------8|7-------------0-
| : | \
SAFE | : | > 256 KByte
FPGA conf. | : | / (NOT usable by software)
0x001c0000 --+- - - - - - - -:- - - - - - - -+-
| : | \
USER | : | > 256 KByte
FPGA conf. | : | / (NOT usable by software)
0x00180000 --+- - - - - - - -:- - - - - - - -+-
| : | \
| : | |
| : | > 512 KByte free for use
0x00140000 --+- - - - - - - -:- - - - - - - -+-|- u-boot _start()
| : | /
0x00100000 ---15------------8|7-------------0-
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/ds/ds_nios_board_apex_20k200e.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
===============================================================================
Stephan Linz <linz@li-pro.net>

136
doc/README.ebony
View File

@ -1,136 +0,0 @@
AMCC Ebony Board
Last Update: September 12, 2002
=======================================================================
This file contains some handy info regarding U-Boot and the AMCC
Ebony evalutation board. See the README.ppc440 for additional
information.
SWITCH SETTINGS & JUMPERS
==========================
Here's what I've been using successfully. If you feel inclined to
change things ... please read the docs!
DIPSW U46 U80
------------------------
SW 1 off on
SW 2 on on
SW 3 on on
SW 4 off on
SW 5 on off
SW 6 on on
SW 7 on off
SW 8 on off
J41: strapped
J42: open
All others are factory default.
I2C iprobe
=====================
The i2c utilities have been tested on both Rev B. and Rev C. and
look good. The CFG_I2C_NOPROBES macro is defined to prevent
probing the CDCV850 clock controller at address 0x69 (since reading
it causes the i2c implementation to misbehave. The output of
iprobe should look like this (assuming you are only using a single
SO-DIMM:
=> iprobe
Valid chip addresses: 50 53 54
Excluded chip addresses: 69
GETTING OUT OF I2C TROUBLE
===========================
If you're like me ... you may have screwed up your bootstrap serial
eeprom ... or worse, your SPD eeprom when experimenting with the
i2c commands. If so, here are some ideas on how to get out of
trouble:
Serial bootstrap eeprom corruption:
-----------------------------------
Power down the board and set the following straps:
J41 - open
J42 - strapped
This will select the default sys0 and sys1 settings (the serial
eeproms are not used). Then power up the board and fix the serial
eeprom using the imm command. Here are the values I currently
use:
=> imd 50 0 10
0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................
=> imd 54 0 10
0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00 ..$.M...........
Once you have the eeproms set correctly change the
J41/J42 straps as you desire.
SPD eeprom corruption:
------------------------
I've corrupted the SPD eeprom several times ... perhaps too much coffee
and not enough presence of mind ;-). By default, the ebony code uses
the SPD to initialize the DDR SDRAM control registers. So if the SPD
eeprom is corrupted, U-Boot will never get into ram. Here's how I got
out of this situation:
0. First, _before_ playing with the i2c utilities, do an iprobe, then
use imd to capture the various device contents to a file. Some day
you may be glad you did this ... trust me :-). Otherwise try the
following:
1. In the include/configs/EBONY.h file find the line that defines
the CONFIG_SPD_EEPROM macro and undefine it. E.g:
#undef CONFIG_SPD_EEPROM
This will make the code use default SDRAM control register
settings without using the SPD eeprom.
2. Rebuild U-Boot
3. Load the new U-Boot image and reboot ebony.
4. Repair the SPD eeprom using the imm command. Here's the eeprom
contents that work with the default SO-DIMM that comes with the
ebony board (micron 8VDDT164AG-265A1). Note: these are probably
_not_ the factory settings ... but they work.
=> imd 53 0 10 80
0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01 ......@..uu.....
0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20 ..... ..u..P<P-
0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00 ..PP.....AK42u..
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c ................
0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36 ,........8VDDT16
0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63 64AG-265A1 ...,c
0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00 "%..............
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
PCI DOUBLE-ENUMERATION WOES
===========================
If you're not using PCI-X cards and are simply using 32-bit and/or
33 MHz cards via extenders and the like, you may notice that the
initial pci scan reports various devices twice ... and configuration
does not succeed (one or more devices are enumerated twice). To correct
this we replaced the 2K ohm resistor on the IDSEL line(s) with a
22 ohm resistor and the problem went away. This change hasn't broken
anything yet -- use at your own risk.
We never tested anything other than 33 MHz/32-bit cards. If you have
the chance to do this, please let me know how things turn out :-)
Regards,
--Scott
<smcnutt@artesyncp.com>

54
doc/README.evb64260
View File

@ -1,54 +0,0 @@
This file contains status information for the port of U-Boot to the
Galileo Evaluation Board.
Author: Josh Huber <huber@mclx.com>
Mission Critical Linux, Inc.
The support for the Galileo Evaluation board is fairly minimal now.
It's sufficient to boot Linux, but doesn't provide too much more than
what's required to do this.
Both DUART channels are supported (to use the second one, you have to
modify the board -- see the schematics for where to solder on the
devices module). The ethernet ports are supported, and the MPSC is
supported as a console driver. (keep in mind that the kernel has no
support for this yet)
There are still occaisonal lockups with the MPSC console driver due to
(we think!) overrun problems. If you're looking for something stable
to use for Linux development, consider sticking with the DUART console
for now.
Automatic memory sizing mostly works. We've had problems with some
combinations of memory. Please send us email if you're having trouble
with respect to the memory detection.
Right now, only the 512k boot flash is supported. Support for the
16MB flash on the devices module is forthcoming. Right now the flash
is stored at the 256k boundry in flash, wasting a whole sector (64k!)
for environment data. This isn't really a big deal since we're not
using the 512k for anything else. (Just U-Boot and the environment)
Finally, here is a sample output session:
U-Boot 1.0.0-pre1 (Jun 6 2001 - 12:45:11)
Initializing...
CPU: MPC7400 (altivec enabled) v2.9
Board: EVB64260
DRAM: 256 MB
FLASH: 512 kB
In: serial
Out: serial
Err: serial
=>
The default configuration should be correct for the evaluation board,
as it's shipped from Galileo. Keep in mind that the default baudrate
is set to 38400, 8N1.
Good luck, and make sure to send any bugreports to us (or the
u-boot-users list).
Josh

89
doc/README.fads
View File

@ -1,89 +0,0 @@
/*
* (C) Copyright 2000
* Dave Ellis, SIXNET, dge@sixnetio.com
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
Using the Motorola MPC8XXFADS development board
===============================================
CONFIGURATIONS
--------------
There are ready-to-use default configurations available for the
FADS823, FADS850SAR and FADS860T. The FADS860T configuration also
works for the 855T processor.
LOADING U-Boot INTO FADS FLASH MEMORY
--------------------------------------
MPC8BUG can load U-Boot into the FLASH memory using LOADF.
loadf u-boot.srec 100000
STARTING U-Boot FROM MPC8BUG
-----------------------------
To start U-Boot from MPC8BUG:
1. Reset the board:
reset :h
2. Change BR0 and OR0 back to their values at reset:
rms memc br0 00000001
rms memc or0 00000d34
3. Modify DER so MPC8BUG gets control only when it should:
rms der 2002000f
4. Start as if from reset:
go 100
This is NOT exactly the same as starting U-Boot without
MPC8BUG. MPC8BUG turns off the watchdog as part of the hard reset.
After it does the reset it writes SYPCR (to disable the watchdog)
and sets BR0 and OR0 to map the FLASH at 0x02800000 (and does lots
of other initialization). That is why it is necessary to set BR0
and OR0 to map the FLASH everywhere. U-Boot can't turn on the
watchdog after that, since MPC8BUG has used the only chance to write
to SYPCR.
Here is a bizarre sequence of MPC8BUG and U-Boot commands that lets
U-Boot write to SYPCR. It works with MPC8BUG 1.5 and an 855T
processor (your mileage may vary). It is probably better (and a lot
easier) just to accept having the watchdog disabled when the debug
cable is connected.
in MPC8BUG:
reset :h
rms memc br0 00000001
rms memc or0 00000d34
rms der 2000f
go 100
Now U-Boot is running with the MPC8BUG value for SYPCR. Use the
U-Boot 'reset' command to reset the board.
=>reset
Next, in MPC8BUG:
rms der 2000f
go
Now U-Boot is running with the U-Boot value for SYPCR.

10
doc/README.idma2intr
View File

@ -1,10 +0,0 @@
(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.

57
doc/README.lynxkdi
View File

@ -1,57 +0,0 @@
LYNX KDI SUPPORT
Last Update: July 20, 2003
=======================================================================
This file describes support for LynuxWorks KDI within U-Boot. Support
is enabled by defining CONFIG_LYNXKDI.
LYNXOS AND BLUECAT SUPPORTED
============================
Both LynxOS and BlueCat linux KDIs are supported. The implementation
automatically detects which is being booted. When you use mkimage
you should specify "lynxos" for both (see target-specific notes).
SUPPORTED ARCHITECTURE/TARGETS
==============================
The following targets have been tested:
-PowerPC MPC8260ADS
FILES TO LOOK AT
================
include/lynxkdi.h -defines a simple struct passed to a kdi.
common/lynxkdi.c -implements the call to the kdi.
common/cmd_bootm.c -top-level command implementation ("bootm").
====================================================================
TARGET SPECIFIC NOTES
====================================================================
MPC8260ADS
===========
The default LynxOS and BlueCat implementations require some
modifications to the config file.
Edit include/configs/MPC8260ADS.h to use the following:
#define CFG_IMMR 0xFA200000
#define CFG_BCSR 0xFA100000
#define CFG_BR1_PRELIM 0xFA101801
When creating a LynxOS or BlueCat u-boot image using mkimage,
you must specify the following:
Both: -A ppc -O lynxos -T kernel -C none
LynxOS: -a 0x00004000 -e 0x00004020
BlueCat: -a 0x00500000 -e 0x00507000
To pass the MAC address to BlueCat you should define the
"fcc2_ether_addr" parameter in the "bootargs" environment
variable. E.g.:
==> setenv bootargs fcc2_ether_addr=00:11:22:33:44:55:66

166
doc/README.m68k
View File

@ -1,166 +0,0 @@
U-Boot for Motorola M68K
====================================================================
History
August 08,2005; Jens Scharsig <esw@bus-elektronik.de>
MCF5282 implementation without preloader
January 12, 2004; <josef.baumgartner@telex.de>
====================================================================
This file contains status information for the port of U-Boot to the
Motorola M68K series of CPUs.
1. OVERVIEW
-----------
Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola Coldfire
architecture. The patches of Bernhard support the MCF5272 and
MCF5282. A great disadvantage of these patches was that they needed
a pre-bootloader to start u-boot. Because of this, a new port was
created which no longer needs a first stage booter.
Although this port is intended to cover all M68k processors, only
the parts for the Motorola Coldfire MCF5272 and MCF5282 are
implemented at the moment. Additional CPUs and boards will be
hopefully added soon!
2. SUPPORTED CPUs
-----------------
2.1 Motorola Coldfire MCF5272
-----------------------------
CPU specific code is located in: cpu/mcf52x2
2.1 Motorola Coldfire MCF5282
-----------------------------
CPU specific code is located in: cpu/mcf52x2
The MCF5282 Port no longer needs a preloader and can place in external or
internal FLASH.
3. SUPPORTED BOARDs
-------------------
3.1 Motorola M5272C3 EVB
------------------------
Board specific code is located in: board/m5272c3
To configure the board, type: make M5272C3_config
U-Boot Memory Map:
------------------
0xffe00000 - 0xffe3ffff u-boot
0xffe04000 - 0xffe05fff environment (embedded in u-boot!)
0xffe40000 - 0xffffffff free for linux/applications
3.2 Motorola M5282 EVB
------------------------
Board specific code is located in: board/m5282evb
To configure the board, type: make M5272C3_config
At the moment the code isn't fully implemented and still needs a pre-loader!
The preloader must initialize the processor and then start u-boot. The board
must be configured for a pre-loader (see 4.1)
For the preloader, please see
http://mailman.uclinux.org/pipermail/uclinux-dev/2003-December/023384.html
U-boot is configured to run at 0x20000 at default. This can be configured by
change TEXT_BASE in board/m5282evb/config.mk and CFG_MONITOR_BASE in
include/configs/M5282EVB.h.
3.2 BuS EB+MCF-EV123
---------------------
Board specific code is located in: board/bus/EB+MCF-EV123
To configure the board, type:
make EB+MCF-EV123_config for external FLASH
make EB+MCF-EV123_internal_config for internal FLASH
4. CONFIGURATION OPTIONS/SETTINGS
----------------------------------
4.1 Configuration to use a pre-loader
-------------------------------------
If u-boot should be loaded to RAM and started by a pre-loader
CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the
initial vector table and basic processor initialization will not
be compiled in. The start address of u-boot must be adjusted in
the boards config header file (CFG_MONITOR_BASE) and Makefile
(TEXT_BASE) to the load address.
4.1 MCF5272 specific Options/Settings
-------------------------------------
CONFIG_MCF52x2 -- defined for all MCF52x2 CPUs
CONFIG_M5272 -- defined for all Motorola MCF5272 CPUs
CONFIG_MONITOR_IS_IN_RAM
-- defined if u-boot is loaded by a pre-loader
CFG_MBAR -- defines the base address of the MCF5272 configuration registers
CFG_INIT_RAM_ADDR
-- defines the base address of the MCF5272 internal SRAM
CFG_ENET_BD_BASE
-- defines the base addres of the FEC buffer descriptors
CFG_SCR -- defines the contents of the System Configuration Register
CFG_SPR -- defines the contents of the System Protection Register
CFG_BRx_PRELIM -- defines the contents of the Chip Select Base Registers
CFG_ORx_PRELIM -- defines the contents of the Chip Select Option Registers
CFG_PxDDR -- defines the contents of the Data Direction Registers
CFG_PxDAT -- defines the contents of the Data Registers
CFG_PXCNT -- defines the contents of the Port Configuration Registers
4.2 MCF5282 specific Options/Settings
-------------------------------------
CONFIG_MCF52x2 -- defined for all MCF52x2 CPUs
CONFIG_M5282 -- defined for all Motorola MCF5282 CPUs
CONFIG_MONITOR_IS_IN_RAM
-- defined if u-boot is loaded by a pre-loader
CFG_MBAR -- defines the base address of the MCF5282 internal register space
CFG_INIT_RAM_ADDR
-- defines the base address of the MCF5282 internal SRAM
CFG_INT_FLASH_BASE
-- defines the base address of the MCF5282 internal Flash memory
CFG_ENET_BD_BASE
-- defines the base addres of the FEC buffer descriptors
CFG_MFD
-- defines the PLL Multiplication Factor Devider
(see table 9-4 of MCF user manual)
CFG_RFD -- defines the PLL Reduce Frecuency Devider
(see table 9-4 of MCF user manual)
CFG_CSx_BASE -- defines the base address of chip select x
CFG_CSx_SIZE -- defines the memory size (address range) of chip select x
CFG_CSx_WIDTH -- defines the bus with of chip select x
CFG_CSx_RO -- if set to 0 chip select x is read/wirte
else chipselct is read only
CFG_CSx_WS -- defines the number of wait states of chip select x
CFG_PxDDR -- defines the contents of the Data Direction Registers
CFG_PxDAT -- defines the contents of the Data Registers
CFG_PXCNT -- defines the contents of the Port Configuration Registers
CFG_PxPAR -- defines the function of ports
5. COMPILER
-----------
To create U-Boot the gcc-2.95.3 compiler set (m68k-elf-20030314) from uClinux.org was used.
You can download it from: http://www.uclinux.org/pub/uClinux/m68k-elf-tools/

128
doc/README.ml300
View File

@ -1,128 +0,0 @@
Xilinx ML300 platform
=====================
0. Introduction
---------------
The Xilinx ML300 board is based on the Virtex-II Pro FPGA with
integrated AMCC PowerPC 405 core. The board is normally booted from
System ACE CF. U-Boot is then run out of main memory.
An FPGA is a configurable and thus very flexible device. To
accommodate for this flexibility this port of U-Boot includes the
required means to regenerate the drivers and configuration files if
you decide to change the hardware design. The required steps are
described below.
1. Requirements
---------------
To compile and run U-Boot on the Xilinx ML300 platform you need the
following items.
- A Xilinx ML300 platform (see http://www.xilinx.com/ml300)
- EDK and ISE development tools (shipping with ML300)
- Parallel4 cable (shipping with ML300)
- The EDK reference design for ML300. You can get this as design #6 from
http://www.xilinx.com/ise/embedded/edk_examples.htm
- A BOOTP/TFTP server
2. Quick Start
--------------
To compile and run U-Boot on ML300 follow the steps below. Make sure
to consult the documentation for U-Boot, EDK, and the EDK reference
design for ML300 if you have any questions.
1. Implement the EDK reference design for ML300. You can use any of
the project files, for example from a xygwin shell:
$ xps -nw system_linux.xmp
XPS% run init_bram
2. Configure and compile U-Boot. Change into the root directory of
U-Boot and run:
$ export CROSS_COMPILE=powerpc-eabi-
$ make ml300_config
$ make
3. Set up the ML300, connect the Parallel4 and the serial cable. Start
a terminal on your host computer and set the communication
parameters to 9600,8N1,no handshake.
4. Set up the BOOTP/TFTP server on your host machine. U-Boot is
preconfigured to use a fixed HW MAC address of 00:0A:35:00:22:01.
5. Download the bitstream to the ML300.
6. Use XMD to download and run U-Boot on the ML300:
$ xmd
XMD% ppcconnect
XMD% dow u-boot
XMD% run
You can now make an ACE file out of bitstream and U-Boot:
$ xmd genace.tcl -jprog -board ml300 -hw \
implementation/download.bit -elf u-boot -ace top.ace
Put the ACE file onto the MicroDrive, for example into xilinx/myace,
and reboot ML300.
3. Generating a Custom BSP for U-Boot
-------------------------------------
If you decide to change the EDK reference design for ML300 or if you
build a new design from scratch either with the Base System Builder in
XPS or all by hand you most likely will change the base addresses for
the Uart and the Ethernet peripheral. If you do so you will have two
options:
1. Edit boards/xilinx/ml300/xparameters.h to reflect the changes you
made to your hardware.
2. Use the MLD technology provided by Xilinx Platform Studio to make
the changes automatically. To do so go to the root directory of the
EDK reference design for ML300. Copy the Linux project file and the
Linux software configuration file:
$ cp system_linux.xmp system_uboot.xmp
$ cp system_linux.mss system_uboot.mss
Edit system_uboot.xmp and and have it point to system_uboot.mss for
the software configuration.
Then, copy the sw_services directory in
boards/xilinx/ml300/sw_services to the root directory of the EDK
reference design for ML300.
$ cp -R <uboot dir>/boards/xilinx/ml300/sw_services <edk dir>
Modify system_uboot.mss. Look for the Linux library definition
and change it to generate a BSP for U-Boot. An example, might look
like this:
BEGIN LIBRARY
PARAMETER LIBRARY_NAME = uboot
PARAMETER LIBRARY_VER = 1.00.a
PARAMETER CONNECTED_PERIPHS = (opb_uart16550_0,opb_ethernet_0)
PARAMETER TARGET_DIR = <uboot dir>
END
Now, you are ready to generate the Xilinx ML300 BSP for U-Boot:
$ xps -nw system_uboot.xmp
XPS% run libs
If all goes well the new configuration has been copied into the
right places within the U-Boot source tree. Recompile U-Boot and
run it on the ML300.
4. ToDo
-------
- Add support for all other peripherals on ML300.
- Read the MAC address out of the IIC EEPROM.
- Store the bootargs in the IIC EEPROM.
5. References
-------------
ML300: http://www.xilinx.com/ml300
EDK: http://www.xilinx.com/edk
ISE: http://www.xilinx.com/ise
Reference Design: http://www.xilinx.com/ise/embedded/edk_examples.htm

62
doc/README.modnet50
View File

@ -1,62 +0,0 @@
U-BOOT Port for FSForth ModNET50 Board
--------------------------------------
author: Thomas Elste <info@elste.org>
IMMS gGmbH <www.imms.de>
The port based upon an early (partial complete)
armboot-port from Stephan Linz for the ModNET50 Board.
Overview:
- board with Netsilicon NET+50 ARM7TDMI CPU without MMU
- 16 MB SDRAM
- 2 MB Flash (MBL29LV160BE)
- 10/100 Ethernet PHY (LXT971A)
Current Configuration (include/configs/modnet50.h):
Memory Map: 0x00000000 - 0x00FFFFFF 16M SDRAM
0x10000000 - 0x101FFFFF 2M Flash
The Flash uses a BB-Architectur with 35 sectors
(0:16K; 1,2:8K; 3:32K; 4-34:64K). U-Boot is located in
the first 5 sectors.
The environment is located at the end of the 4th Flash
sector (0x1001C000-0x1001FFFF).
Build:
U-boot should be build by using the ELDK Toolchain (arm-linux-*).
make modnet50_config
make
Status:
Everything seems to work fine. Booting images was tested by
booting uCLinux (with and without a separate ramdisk image) from
flash.
Files:
cpu/arm720t/serial_netarm.c .. serial I/O for the cpu
board/modnet50/lowlevel_init.S .. memory setup for ModNET50
board/modnet50/flash.c .. flash routines
board/modnet50/modnet50.c .. some board init stuff
drivers/netarm_eth.c .. ethernet driver for the NET+50 CPU
drivers/netarm_eth.h .. header for ethernet driver
include/configs/modnet50.h .. configuration file for ModNET50
include/netarm_*.h .. register and macro definitions for
the NETARM CPU family
doc/README.modnet50 .. this readme

48
doc/README.mpc5xx
View File

@ -1,48 +0,0 @@
Summary:
========
This file contains information about the port of U-Boot to the
Motorola mpc5xx series of CPUs. Most of this code is taken from
existing code mainly from the mpc8xx port. In contrast to mpc8xx,
the mpc5xx has no CPM, MMU and cache facilities.
The implemented features have been tested on the cmi board, a
customer specific board (see README.cmi).
Hence this port is only tested on the cmi board further possible
tests on other boards will be very valuable.
Not Tested Features:
====================
* System calls
* Interrupts
Added or Changed Files:
=======================
u-boot-0.2.0/common/cmd_boot.c
u-boot-0.2.0/common/cmd_reginfo.c
u-boot-0.2.0/common/environment.c
u-boot-0.2.0/cpu/mpc5xx/*
u-boot-0.2.0/include/cmd_reginfo.h
u-boot-0.2.0/include/common.h
u-boot-0.2.0/include/ppc_asm.tmpl
u-boot-0.2.0/include/watchdog.h
u-boot-0.2.0/include/mpc5xx.h
u-boot-0.2.0/include/status_led.h
u-boot-0.2.0/include/asm-ppc/u-boot.h
u-boot-0.2.0/include/asm-ppc/5xx_immap.h
u-boot-0.2.0/lib_ppc/board.c
u-boot-0.2.0/lib_ppc/cache.c
u-boot-0.2.0/lib_ppc/time.c
u-boot-0.2.0/Makefile
u-boot-0.2.0/CREDITS
u-boot-0.2.0/doc/README.mpc5xx
u-boot-0.2.0/doc/README.cmi
u-boot-0.2.0/README
u-boot-0.2.0/MAKEALL
Regards,
Martin

22
doc/README.mpc74xx
View File

@ -1,22 +0,0 @@
This file contains status information for the port of U-Boot to the
Motorola mpc74xx series of CPUs.
Author: Josh Huber <huber@mclx.com>
Mission Critical Linux, Inc.
Currently the support for these CPUs is pretty minimal, but enough to
get things going. (much like the support for the Galileo Eval Board)
There is a framework in place to enable the L2 cache, and to program
the BATs. Currently, there are still problems with the code which
sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be
anyway). Additionally, there is support for enabling the MMU, which
we also don't do. The BATs are programmed just for the benefit of
jumping into Linux in a sane configuration.
Most of the code was based on other cpus supported by U-Boot.
If you find any errors in the CPU setup code, please send us a note.
Thanks,
Josh

154
doc/README.mpc8349emds.ddrecc
View File

@ -1,154 +0,0 @@
Overview
========
The overall usage pattern for ECC diagnostic commands is the following:
* (injecting errors is initially disabled)
* define inject mask (which tells the DDR controller what type of errors
we'll be injecting: single/multiple bit etc.)
* enable injecting errors - from now on the controller injects errors as
indicated in the inject mask
IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially
dangerous as such errors are NOT corrected by the controller. Therefore caution
should be taken when enabling the injection of multiple-bit errors: it is only
safe when used on a carefully selected memory area and used under control of
the 'ecc test' command (see example 'Injecting Multiple-Bit Errors' below). In
particular, when you simply set the multiple-bit errors in inject mask and
enable injection, U-Boot is very likely to hang quickly as the errors will be
injected when it accesses its code, data etc.
Use cases for DDR 'ecc' command:
================================
Before executing particular tests reset target board or clear status registers:
=> ecc captureclear
=> ecc errdetectclr all
=> ecc sbecnt 0
Injecting Single-Bit Errors
---------------------------
1. Set 1 bit in Data Path Error Inject Mask
=> ecc injectdatahi 1
2. Run test over some memory region
=> ecc test 200000 10
3. Check ECC status
=> ecc status
...
Memory Data Path Error Injection Mask High/Low: 00000001 00000000
...
Memory Single-Bit Error Management (0..255):
Single-Bit Error Threshold: 255
Single Bit Error Counter: 16
...
Memory Error Detect:
Multiple Memory Errors: 0
Multiple-Bit Error: 0
Single-Bit Error: 0
...
16 errors were generated, Single-Bit Error flag was not set as Single Bit Error
Counter did not reach Single-Bit Error Threshold.
4. Make sure used memory region got re-initialized with 0xcafecafe pattern
=> md 200000
00200000: cafecafe cafecafe cafecafe cafecafe ................
00200010: cafecafe cafecafe cafecafe cafecafe ................
00200020: cafecafe cafecafe cafecafe cafecafe ................
00200030: cafecafe cafecafe cafecafe cafecafe ................
00200040: cafecafe cafecafe cafecafe cafecafe ................
00200050: cafecafe cafecafe cafecafe cafecafe ................
00200060: cafecafe cafecafe cafecafe cafecafe ................
00200070: cafecafe cafecafe cafecafe cafecafe ................
00200080: deadbeef deadbeef deadbeef deadbeef ................
00200090: deadbeef deadbeef deadbeef deadbeef ................
Injecting Multiple-Bit Errors
-----------------------------
1. Set more than 1 bit in Data Path Error Inject Mask
=> ecc injectdatahi 5
2. Run test over some memory region
=> ecc test 200000 10
3. Check ECC status
=> ecc status
...
Memory Data Path Error Injection Mask High/Low: 00000005 00000000
...
Memory Error Detect:
Multiple Memory Errors: 1
Multiple-Bit Error: 1
Single-Bit Error: 0
...
Observe that both Multiple Memory Errors and Multiple-Bit Error flags are set.
4. Make sure used memory region got re-initialized with 0xcafecafe pattern
=> md 200000
00200000: cafecafe cafecafe cafecafe cafecafe ................
00200010: cafecafe cafecafe cafecafe cafecafe ................
00200020: cafecafe cafecafe cafecafe cafecafe ................
00200030: cafecafe cafecafe cafecafe cafecafe ................
00200040: cafecafe cafecafe cafecafe cafecafe ................
00200050: cafecafe cafecafe cafecafe cafecafe ................
00200060: cafecafe cafecafe cafecafe cafecafe ................
00200070: cafecafe cafecafe cafecafe cafecafe ................
00200080: deadbeef deadbeef deadbeef deadbeef ................
00200090: deadbeef deadbeef deadbeef deadbeef ................
Test Single-Bit Error Counter and Threshold
-------------------------------------------
1. Set 1 bit in Data Path Error Inject Mask
=> ecc injectdatahi 1
2. Enable error injection
=> ecc inject en
3. Let u-boot run for a with Single-Bit error injection enabled
4. Disable error injection
=> ecc inject dis
4. Check status
=> ecc status
...
Memory Single-Bit Error Management (0..255):
Single-Bit Error Threshold: 255
Single Bit Error Counter: 60
Memory Error Detect:
Multiple Memory Errors: 1
Multiple-Bit Error: 0
Single-Bit Error: 1
...
Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter
reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that
is Counter reached Threshold more than one time (it wraps back after reaching
Threshold).

126
doc/README.mpc8360emds
View File

@ -1,126 +0,0 @@
Freescale MPC8360EMDS Board
-----------------------------------------
1. Board Switches and Jumpers
1.0 There are four Dual-In-Line Packages(DIP) Switches on MPC8360EMDS board
For some reason, the HW designers describe the switch settings
in terms of 0 and 1, and then map that to physical switches where
the label "On" refers to logic 0 and "Off" is logic 1.
Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
bits may contribute to signals that are numbered based at 0,
and some of those signals may be high-bit-number-0 too. Heed
well the names and labels and do not get confused.
"Off" == 1
"On" == 0
SW18 is switch 18 as silk-screened onto the board.
SW4[8] is the bit labled 8 on Switch 4.
SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2.
SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3.
SW3[1:8]= 0000_0001 refers to bits labeled 1 through 6 is set as "On"
and bits labeled 8 is set as "Off".
1.1 For the MPC8360E PB PROTO Board
First, make sure the board default setting is consistent with the
document shipped with your board. Then apply the following setting:
SW3[1-8]= 0000_0100 (HRCW setting value is performed on local bus)
SW4[1-8]= 0011_0000 (Flash boot on local bus)
SW9[1-8]= 0110_0110 (PCI Mode enabled. HRCW is read from FLASH)
SW10[1-8]= 0000_1000 (core PLL setting)
SW11[1-8]= 0000_0100 (SW11 is on the another side of the board)
JP6 1-2
on board Oscillator: 66M
2. Memory Map
2.1. The memory map should look pretty much like this:
0x0000_0000 0x7fff_ffff DDR 2G
0x8000_0000 0x8fff_ffff PCI MEM prefetch 256M
0x9000_0000 0x9fff_ffff PCI MEM non-prefetch 256M
0xc000_0000 0xdfff_ffff Empty 512M
0xe000_0000 0xe01f_ffff Int Mem Reg Space 2M
0xe020_0000 0xe02f_ffff Empty 1M
0xe030_0000 0xe03f_ffff PCI IO 1M
0xe040_0000 0xefff_ffff Empty 252M
0xf000_0000 0xf3ff_ffff Local Bus SDRAM 64M
0xf400_0000 0xf7ff_ffff Empty 64M
0xf800_0000 0xf800_7fff BCSR on CS1 32K
0xf800_8000 0xf800_ffff PIB CS4 32K
0xf801_0000 0xf801_7fff PIB CS5 32K
0xfe00_0000 0xfeff_ffff FLASH on CS0 16M
3. Definitions
3.1 Explanation of NEW definitions in:
include/configs/MPC8360EMDS.h
CONFIG_MPC83XX MPC83xx family for both MPC8349 and MPC8360
CONFIG_MPC8360 MPC8360 specific
CONFIG_MPC8360EMDS MPC8360EMDS board specific
4. Compilation
Assuming you're using BASH shell:
export CROSS_COMPILE=your-cross-compile-prefix
cd u-boot
make distclean
make MPC8360EMDS_config
make
MPC8360 support PCI in host and slave mode.
To make u-boot support PCI host 66M :
1) DIP SW support PCI mode as described in Section 1.1.
2) Make MPC8360EMDS_HOST_66_config
To make u-boot support PCI host 33M :
1) DIP SW setting is similar as Section 1.1, except for SW3[4] is 1
2) Make MPC8360EMDS_HOST_33_config
To make u-boot support PCI slave 66M :
1) DIP SW setting is similar as Section 1.1, except for SW9[3] is 1
2) Make MPC8360EMDS_SLAVE_config
5. Downloading and Flashing Images
5.0 Download over serial line using Kermit:
loadb
[Drop to kermit:
^\c
send <u-boot-bin-image>
c
]
Or via tftp:
tftp 10000 u-boot.bin
5.1 Reflash U-boot Image using U-boot
tftp 20000 u-boot.bin
protect off fef00000 fef3ffff
erase fef00000 fef3ffff
cp.b 20000 fef00000 xxxx
or
cp.b 20000 fef00000 3ffff
You have to supply the correct byte count with 'xxxx' from the TFTP result log.
Maybe 3ffff will work too, that corresponds to the erased sectors.
6. Notes
1) The console baudrate for MPC8360EMDS is 115200bps.

98
doc/README.mpc83xxads
View File

@ -1,98 +0,0 @@
Freescale MPC83xx ADS Boards
-----------------------------------------
0. Toolchain / Building
$ PATH=$PATH:/usr/powerpc/bin
$ CROSS_COMPILE=powerpc-linux-
$ export PATH CROSS_COMPILE
$ powerpc-linux-gcc -v
Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr/powerpc
--exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared
--disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc
Thread model: posix
gcc version 3.4.3 (Debian)
$ powerpc-linux-as -v
GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15
$ make MPC8349ADS_config
Configuring for MPC8349ADS board...
$ make
1. Board Switches and Jumpers
2. Memory Map
2.1. The memory map should look pretty much like this:
0x0000_0000 0x7fff_ffff DDR 2G
0x8000_0000 0x9fff_ffff PCI MEM 512M
0xc000_0000 0xdfff_ffff Rapid IO 512M
0xe000_0000 0xe00f_ffff CCSR 1M
0xe200_0000 0xe2ff_ffff PCI IO 16M
0xf000_0000 0xf7ff_ffff SDRAM 128M
0xf800_0000 0xf80f_ffff BCSR 1M
0xfe00_0000 0xffff_ffff FLASH (boot bank) 16M
3. Definitions
3.1 Explanation of NEW definitions in:
include/configs/MPC8349ADS.h
CONFIG_MPC83xx MPC83xx family
CONFIG_MPC8349 MPC8349 specific
CONFIG_MPC8349ADS MPC8349ADS board specific
CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet
4. Compilation
Assuming you're using BASH shell:
export CROSS_COMPILE=your-cross-compile-prefix
cd u-boot
make distclean
make MPC8349ADS_config
make
5. Downloading and Flashing Images
5.0 Download over serial line using Kermit:
loadb
[Drop to kermit:
^\c
send <u-boot-bin-image>
c
]
Or via tftp:
tftp 10000 u-boot.bin
5.1 Reflash U-boot Image using U-boot
tftp 10000 u-boot.bin
protect off fe000000 fe09ffff
erase fe000000 fe09ffff
cp.b 10000 fe000000 xxxx
or
cp.b 10000 fe000000 a0000
You might have to supply the correct byte count for 'xxxx' from
the TFTP. Maybe a0000 will work too, that corresponds to the
erased sectors.
6. Notes

303
doc/README.mpc85xxads
View File

@ -1,303 +0,0 @@
Motorola MPC8540ADS and MPC8560ADS board
Created 10/15/03 Xianghua Xiao
Updated 13-July-2004 Jon Loeliger
-----------------------------------------
0. Toolchain
The Binutils in current ELDK toolchain will not support MPC85xx
chip. You need to use binutils-2.14.tar.bz2 (or newer) from
http://ftp.gnu.org/gnu/binutils.
The 8540/8560 ADS code base is known to compile using:
gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
1. SWITCH SETTINGS & JUMPERS
1.0 Nomenclature
For some reason, the HW designers describe the switch settings
in terms of 0 and 1, and then map that to physical switches where
the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1.
Luckily, we're SW types and virtual settings are handled daily.
The switches for the Rev A board are numbered differently than
for the Pilot board. Oh yeah.
Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
bits may contribute to signals that are numbered based at 0,
and some of those signals may be high-bit-number-0 too. Heed
well the names and labels and do not get confused.
"Off" == 1
"On" == 0
SW18 is switch 18 as silk-screened onto the board.
SW4[8] is the bit labled 8 on Switch 4.
SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2
SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3
1.1 For the MPC85xxADS Pilot Board
First, make sure the board default setting is consistent with the document
shipped with your board. Then apply the following changes:
SW3[1-6]="all OFF" (boot from 32bit flash, no boot sequence is used)
SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560)
SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode)
SW11[7]='ON' (rev2), 'OFF' (rev1)
SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector)
SW22[1-4]="OFF OFF ON OFF"
SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF"
J1 = "Enable Prog" (Make sure your flash is programmable for development)
If you want to test PCI functionality with a 33Mhz PCI card, you will
have to change the system clock from the default 66Mhz to 33Mhz by
setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need
double your platform clock(SW6) because the system clock is now only
half of its original value. For example, if at 66MHz your system
clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10.
SW17[8] ------+ SW6
SW15[1] ----+ | [0:1]
V V V V
33MHz 1 1 1 0
66MHz 0 0 0 1
Hmmm... That SW6 setting description is incomplete but it works.
1.3 For the MPC85xxADS Rev A Board
As shipped, the board should be a 33MHz PCI bus with a CPU Clock
rate of 825 +/- fuzz:
Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
For 33MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 1 => PWD Divider == 16
SW16[1:2] = 11 => N == 16 as PWD==1
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz
SW7[1:4] = 1010 = 10 => 10 x 33 = 330 CCB Sysclk
SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
For 66MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 0 => PWD Divider == 1
SW16[1:2] = 01 => N == 8 as PWD == 0
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz
SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB Sysclk
SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
In order to use PCI-X (only in the first PCI slot. The one with
the RIO connector), you need to set SW1[4] (config) to 1 (off).
Also, configure the board to run PCI at 66 MHz.
2. MEMORY MAP TO WORK WITH LINUX KERNEL
2.1. For the initial bringup, we adopted a consistent memory scheme
between u-boot and linux kernel, you can customize it based on your
system requirements:
0x0000_0000 0x7fff_ffff DDR 2G
0x8000_0000 0x9fff_ffff PCI MEM 512M
0xc000_0000 0xdfff_ffff Rapid IO 512M
0xe000_0000 0xe00f_ffff CCSR 1M
0xe200_0000 0xe2ff_ffff PCI IO 16M
0xf000_0000 0xf7ff_ffff SDRAM 128M
0xf800_0000 0xf80f_ffff BCSR 1M
0xff00_0000 0xffff_ffff FLASH (boot bank) 16M
2.2 We are submitting Linux kernel patches for MPC8540 and MPC8560. You
can download them from linuxppc-2.4 public source. Please make sure the
kernel's ppcboot.h is consistent with U-Boot's u-boot.h. You can use two
default configuration files as your starting points to configure the
kernel:
arch/ppc/configs/mpc8540_ads_defconfig
arch/ppc/configs/mpc8560_ads_defconfig
3. DEFINITIONS AND COMPILATION
3.1 Explanation on NEW definitions in:
include/configs/MPC8540ADS.h
include/configs/MPC8560ADS.h
CONFIG_BOOKE BOOKE(e.g. Motorola MPC85xx, AMCC 440, etc)
CONFIG_E500 BOOKE e500 family(Motorola)
CONFIG_MPC85xx MPC8540,MPC8560 and their derivatives
CONFIG_MPC8540 MPC8540 specific
CONFIG_MPC8540ADS MPC8540ADS board specific
CONFIG_MPC8560ADS MPC8560ADS board specific
CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet for networking
CONFIG_SPD_EEPROM Use SPD EEPROM for DDR auto configuration, you can
also manual config the DDR after undef this
definition.
CONFIG_DDR_ECC only for ECC DDR module
CONFIG_DDR_DLL DLL fix on some ADS boards needed for more
stability.
CONFIG_HAS_FEC If an FEC is on chip, set to 1, else 0.
Other than the above definitions, the rest in the config files are
straightforward.
3.2 Compilation
Assuming you're using BASH shell:
export CROSS_COMPILE=your-cross-compile-prefix
cd u-boot
make distclean
make MPC8560ADS_config (or make MPC8540ADS_config)
make
4. Notes:
4.1 When connecting with kermit, the following commands must be present.in
your .kermrc file. These are especially important when booting as
MPC8560, as the serial console will not work without them:
set speed 115200
set carrier-watch off
set handshake none
set flow-control none
robust
4.2 Sometimes after U-Boot is up, the 'tftp' won't work well with TSEC
ethernet. If that happens, you can try the following steps to make
network work:
MPC8560ADS>tftp 1000000 pImage
(if it hangs, use Ctrl-C to quit)
MPC8560ADS>nm fdf24524
>0
>1
>. (to quit this memory operation)
MPC8560ADS>tftp 1000000 pImage
4.3 If you're one of the early developers using the Rev1 8540/8560 chips,
please use U-Boot 1.0.0, as the newer silicon will only support Rev2
and future revisions of 8540/8560.
4.4 Reflash U-boot Image using U-boot
tftp 10000 u-boot.bin
protect off fff80000 ffffffff
erase fff80000 ffffffff
cp.b 10000 fff80000 80000
4.5 Reflash U-Boot with a BDI-2000
BDI> erase 0xFFF80000 0x4000 0x20
BDI> prog 0xfff80000 u-boot.bin.8560ads
BDI> verify
5. Screen dump MPC8540ADS board
U-Boot 1.1.2(pq3-20040707-0) (Jul 6 2004 - 17:34:25)
Freescale PowerPC
Core: E500, Version: 2.0, (0x80200020)
System: 8540, Version: 2.0, (0x80300020)
Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
Board: ADS
PCI1: 32 bit, 66 MHz (compiled)
I2C: ready
DRAM: Initializing
SDRAM: 64 MB
DDR: 256 MB
FLASH: 16 MB
L2 cache enabled: 256KB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: MOTO ENET0: PHY is Marvell 88E1011S (1410c62)
MOTO ENET1: PHY is Marvell 88E1011S (1410c62)
MOTO ENET2: PHY is Davicom DM9161E (181b881)
MOTO ENET0, MOTO ENET1, MOTO ENET2
Hit any key to stop autoboot: 0
=>
=> fli
Bank # 1: Intel 28F640J3A (64 Mbit, 64 x 128K)
Size: 16 MB in 64 Sectors
Sector Start Addresses:
FF000000 FF040000 FF080000 FF0C0000 FF100000
FF140000 FF180000 FF1C0000 FF200000 FF240000
FF280000 FF2C0000 FF300000 FF340000 FF380000
FF3C0000 FF400000 FF440000 FF480000 FF4C0000
FF500000 FF540000 FF580000 FF5C0000 FF600000
FF640000 FF680000 FF6C0000 FF700000 FF740000
FF780000 FF7C0000 FF800000 FF840000 FF880000
FF8C0000 FF900000 FF940000 FF980000 FF9C0000
FFA00000 FFA40000 FFA80000 FFAC0000 FFB00000
FFB40000 FFB80000 FFBC0000 FFC00000 FFC40000
FFC80000 FFCC0000 FFD00000 FFD40000 FFD80000
FFDC0000 FFE00000 FFE40000 FFE80000 FFEC0000
FFF00000 FFF40000 FFF80000 (RO) FFFC0000 (RO)
=> bdinfo
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xE0000000
bootflags = 0xE4013F80
intfreq = 825 MHz
busfreq = 330 MHz
ethaddr = 00:E0:0C:00:00:FD
eth1addr = 00:E0:0C:00:01:FD
eth2addr = 00:E0:0C:00:02:FD
IP addr = 192.168.1.253
baudrate = 115200 bps
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;bootm $loadaddr $ramdiskaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
bootdelay=10
baudrate=115200
loads_echo=1
ethaddr=00:E0:0C:00:00:FD
eth1addr=00:E0:0C:00:01:FD
eth2addr=00:E0:0C:00:02:FD
ipaddr=192.168.1.253
serverip=192.168.1.1
rootpath=/nfsroot
gatewayip=192.168.1.1
netmask=255.255.255.0
hostname=unknown
bootfile=your.uImage
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=your.ramdisk.u-boot
stdin=serial
stdout=serial
stderr=serial
ethact=MOTO ENET0
Environment size: 1020/8188 bytes

225
doc/README.mpc85xxcds
View File

@ -1,225 +0,0 @@
Motorola MPC85xxCDS boards
--------------------------
The CDS family of boards consists of a PCI backplane called the
"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot,
and a CPU daughter card that bolts onto the daughter card.
Much of the content of the README.mpc85xxads for the 85xx ADS boards
applies to the 85xx CDS boards as well. In particular the toolchain,
the switch nomenclature, and the basis for the memory map. There are
some differences, though.
Building U-Boot
---------------
The Binutils in current ELDK toolchain will not support MPC85xx
chip. You need to use binutils-2.14.tar.bz2 (or newer) from
http://ftp.gnu.org/gnu/binutils.
The 85xx CDS code base is known to compile using:
gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
Memory Map
----------
The memory map for u-boot and linux has been extended w.r.t. the ADS
platform to allow for utilization of all 85xx CDS devices. The memory
map is setup for linux to operate properly. The linux source when
configured for MPC85xx CDS has been updated to reflect the new memory
map.
The mapping is:
0x0000_0000 0x7fff_ffff DDR 2G
0x8000_0000 0x9fff_ffff PCI1 MEM 512M
0xa000_0000 0xbfff_ffff PCI2 MEM 512M
0xe000_0000 0xe00f_ffff CCSR 1M
0xe200_0000 0xe2ff_ffff PCI1 IO 16M
0xe300_0000 0xe3ff_ffff PCI2 IO 16M
0xf000_0000 0xf7ff_ffff SDRAM 128M
0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M
0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M
0xff80_0000 0xffff_ffff FLASH (boot bank) 8M
(*) The system control registers (CADMUS) start at offset 0xfdb0_4000
within the NVRAM/CADMUS region of memory.
Using Flash
-----------
The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000).
There is a switch which allows the boot-bank to be selected. The switch
settings for updating flash are given below.
The u-boot commands for copying the boot-bank into the secondary bank are
as follows:
erase ff780000 ff7fffff
cp.b fff80000 ff780000 80000
U-boot/kermit commands for downloading an image, then copying
it into the secondary bank:
loadb
[Drop to kermit:
^\c
send <u-boot-bin-image>
c
]
erase ff780000 ff7fffff
cp.b $loadaddr ff780000 80000
U-boot commands for downloading an image via tftp and flashing
it into the second bank:
tftp 10000 <u-boot.bin.image>
erase ff780000 ff7fffff
cp.b 10000 ff780000 80000
After copying the image into the second bank of flash, be sure to toggle
SW2[2] on the carrier card before resetting the board in order to set the
secondary bank as the boot-bank.
Carrier Board Switches
----------------------
As a reminder, you should read the README.mpc85xxads too.
Most switches on the carrier board should not be changed. The only
user-settable switches on the carrier board are used to configure
the flash banks and determining the PCI slot.
The first two bits of SW2 control how flash is used on the board:
12345678
--------
SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available.
01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped).
10XXXXXX FLASH: Boot promjet, bank 1 available
11XXXXXX FLASH: Boot promjet, bank 2 available
The boot bank is always mapped to FF80_0000 and listed first by
the "flinfo" command. The secondary bank is always FF00_0000.
When using PCI, linux needs to know to which slot the CDS carrier is
connected.. By convention, the user-specific bits of SW2 are used to
convey this information:
12345678
--------
SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia
xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia
xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia
xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia
These are cleverly, er, clearly silkscreened as Slot 1 through 4,
respectively, on the Arcadia near the support posts.
The default setting of all switches on the carrier board is:
12345678
--------
SW1=01101100
SW2=0x1111yy x=Flash bank, yy=PCI slot
SW3=11101111
SW4=10001000
8555/41 CPU Card Switches
-------------------------
Most switches on the CPU Card should not be changed. However, the
frequency can be changed by setting SW3:
12345678
--------
SW3=XX00XXXX == CORE:CCB 2:1
XX01XXXX == CORE:CCB 5:2
XX10XXXX == CORE:CCB 3:1
XX11XXXX == CORE:CCB 7:2
XXXX1000 == CCB:SYSCLK 8:1
XXXX1010 == CCB:SYSCLK 10:1
A safe default setting for all switches on the CPU board is:
12345678
--------
SW1=10001111
SW2=01000111
SW3=00001000
SW4=11111110
8548 CPU Card Switches
----------------------
And, just to be confusing, in this set of switches:
ON = 1
OFF = 0
Default
SW1=11111101
SW2=10011111
SW3=11001000 (8X) (2:1)
SW4=11110011
SW3=X000XXXX == CORE:CCB 4:1
X001XXXX == CORE:CCB 9:2
X010XXXX == CORE:CCB 1:1
X011XXXX == CORE:CCB 3:2
X100XXXX == CORE:CCB 2:1
X101XXXX == CORE:CCB 5:2
X110XXXX == CORE:CCB 3:1
X111XXXX == CORE:CCB 7:2
XXXX0000 == CCB:SYSCLK 16:1
XXXX0001 == RESERVED
XXXX0010 == CCB:SYSCLK 2:1
XXXX0011 == CCB:SYSCLK 3:1
XXXX0100 == CCB:SYSCLK 4:1
XXXX0101 == CCB:SYSCLK 5:1
XXXX0110 == CCB:SYSCLK 6:1
XXXX0111 == RESERVED
XXXX1000 == CCB:SYSCLK 8:1
XXXX1001 == CCB:SYSCLK 9:1
XXXX1010 == CCB:SYSCLK 10:1
XXXX1011 == RESERVED
XXXX1100 == CCB:SYSCLK 12:1
XXXX1101 == CCB:SYSCLK 20:1
XXXX1110 == RESERVED
XXXX1111 == RESERVED
eDINK Info
----------
One bank of flash may contain an eDINK image.
Memory Map:
CCSRBAR @ 0xe0000000
Flash Bank 1 @ 0xfe000000
Flash Bank 2 @ 0xff000000
Ram @ 0
Commands for downloading a u-boot image to memory from edink:
env -c
time -s 4/8/2004 4:30p
dl -k -b -o 100000
[Drop to kermit:
^\c
transmit /binary <u-boot-bin-image>
c
]
fu -l 100000 fe780000 80000

123
doc/README.mpc8641hpcn
View File

@ -1,123 +0,0 @@
Freescale MPC8641HPCN board
===========================
Created 05/24/2006 Haiying Wang
-------------------------------
1. Building U-Boot
------------------
The 86xx HPCN code base is known to compile using:
Binutils 2.15, Gcc 3.4.3, Glibc 2.3.3
$ make MPC8641HPCN_config
Configuring for MPC8641HPCN board...
$ make
2. Switch and Jumper Setting
----------------------------
Jumpers:
J14 Pins 1-2 (near plcc32 socket)
Switches:
SW1(1-5) = 01100 CFG_COREPLL = 01000 :: CORE = 2:1
01100 :: CORE = 2.5:1
10000 :: CORE = 3:1
11100 :: CORE = 3.5:1
10100 :: CORE = 4:1
01110 :: CORE = 4.5:1
SW1(6-8) = 001 CFG_SYSCLK = 000 :: SYSCLK = 33MHz
001 :: SYSCLK = 40MHz
SW2(1-4) = 1100 CFG_CCBPLL = 0010 :: 2X
0100 :: 4X
0110 :: 6X
1000 :: 8X
1010 :: 10X
1100 :: 12X
1110 :: 14X
0000 :: 16X
SW2(5-8) = 1110 CFG_BOOTLOC = 1110 :: boot 16-bit localbus
SW3(1-7) = 0011000 CFG_VID = 0011000 :: VCORE = 1.2V
0100000 :: VCORE = 1.11V
SW3(8) = 0 VCC_PLAT = 0 :: VCC_PLAT = 1.2V
1 :: VCC_PLAT = 1.0V
SW4(1-2) = 11 CFG_HOSTMODE = 11 :: both prots host/root
SW4(3-4) = 11 CFG_BOOTSEQ = 11 :: no boot seq
SW4(5-8) = 0011 CFG_IOPORT = 0011 :: both PEX
SW5(1) = 1 CFG_FLASHMAP = 1 :: boot from flash
0 :: boot from PromJet
SW5(2) = 1 CFG_FLASHBANK = 1 :: swap upper/lower
halves (virtual banks)
0 :: normal
SW5(3) = 0 CFG_FLASHWP = 0 :: not protected
SW5(4) = 0 CFG_PORTDIV = 1 :: 2:1 for PD4
1:1 for PD6
SW5(5-6) = 11 CFG_PIXISOPT = 11 :: s/w determined
SW5(7-8) = 11 CFG_LADOPT = 11 :: s/w determined
SW6(1) = 1 CFG_CPUBOOT = 1 :: no boot holdoff
SW6(2) = 1 CFG_BOOTADDR = 1 :: no traslation
SW6(3-5) = 000 CFG_REFCLKSEL = 000 :: 100MHZ
SW6(6) = 1 CFG_SERROM_ADDR= 1 ::
SW6(7) = 1 CFG_MEMDEBUG = 1 ::
SW6(8) = 1 CFG_DDRDEBUG = 1 ::
SW8(1) = 1 ACZ_SYNC = 1 :: 48MHz on TP49
SW8(2) = 1 ACB_SYNC = 1 :: THRMTRIP disabled
SW8(3) = 1 ACZ_SDOUT = 1 :: p4 mode
SW8(4) = 1 ACB_SDOUT = 1 :: PATA freq. = 133MHz
SW8(5) = 0 SUSLED = 0 :: SouthBridge Mode
SW8(6) = 0 SPREAD = 0 :: REFCLK SSCG Disabled
SW8(7) = 1 ACPWR = 1 :: non-battery
SW8(8) = 0 CFG_IDWP = 0 :: write enable
3. Flash U-Boot
---------------
The flash range 0xFF800000 to 0xFFFFFFFF can be divided into 2 halves.
It is possible to use either half to boot using u-boot. Switch 5 bit 2
is used for this purpose.
0xFF800000 to 0xFFBFFFFF - 4MB
0xFFC00000 to 0xFFFFFFFF - 4MB
When this bit is 0, U-Boot is at 0xFFF00000.
When this bit is 1, U-Boot is at 0xFFB00000.
Use the above mentioned flash commands to program the other half, and
use switch 5, bit 2 to alternate between the halves. Note: The booting
version of U-Boot will always be at 0xFFF00000.
To Flash U-Boot into the booting bank (0xFFC00000 - 0xFFFFFFFF):
tftp 1000000 u-boot.bin
protect off all
erase fff00000 ffffffff
cp.b 1000000 fff00100 80000
To Flash U-boot into the alternative bank (0xFF800000 - 0xFFBFFFFF):
tftp 1000000 u-boot.bin
erase ffb00000 ffbfffff
cp.b 1000000 ffb00100 80000
4. Memory Map
-------------
Memory Range Device Size
------------ ------ ----
0x0000_0000 0x7fff_ffff DDR 2G
0x8000_0000 0x9fff_ffff PCI1/PEX1 MEM 512M
0xa000_0000 0xafff_ffff PCI2/PEX2 MEM 512M
0xf800_0000 0xf80f_ffff CCSR 1M
0xf810_0000 0xf81f_ffff PIXIS 1M
0xf840_0000 0xf840_3fff Stack space 32K
0xe200_0000 0xe2ff_ffff PCI1/PEX1 IO 16M
0xe300_0000 0xe3ff_ffff PCI2/PEX2 IO 16M
0xfe00_0000 0xfeff_ffff Flash(alternate)16M
0xff00_0000 0xffff_ffff Flash(boot bank)16M

255
doc/README.nand
View File

@ -1,255 +0,0 @@
NAND FLASH commands and notes
See NOTE below!!!
# (C) Copyright 2003
# Dave Ellis, SIXNET, dge@sixnetio.com
#
# See file CREDITS for list of people who contributed to this
# project.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
Commands:
nand bad
Print a list of all of the bad blocks in the current device.
nand device
Print information about the current NAND device.
nand device num
Make device `num' the current device and print information about it.
nand erase off|partition size
nand erase clean [off|partition size]
Erase `size' bytes starting at offset `off'. Alternatively partition
name can be specified, in this case size will be eventually limited
to not exceed partition size (this behaviour applies also to read
and write commands). Only complete erase blocks can be erased.
If `erase' is specified without an offset or size, the entire flash
is erased. If `erase' is specified with partition but without an
size, the entire partition is erased.
If `clean' is specified, a JFFS2-style clean marker is written to
each block after it is erased.
This command will not erase blocks that are marked bad. There is
a debug option in cmd_nand.c to allow bad blocks to be erased.
Please read the warning there before using it, as blocks marked
bad by the manufacturer must _NEVER_ be erased.
nand info
Print information about all of the NAND devices found.
nand read addr ofs|partition size
Read `size' bytes from `ofs' in NAND flash to `addr'. If a page
cannot be read because it is marked bad or an uncorrectable data
error is found the command stops with an error.
nand read.jffs2 addr ofs|partition size
Like `read', but the data for blocks that are marked bad is read as
0xff. This gives a readable JFFS2 image that can be processed by
the JFFS2 commands such as ls and fsload.
nand read.oob addr ofs|partition size
Read `size' bytes from the out-of-band data area corresponding to
`ofs' in NAND flash to `addr'. This is limited to the 16 bytes of
data for one 512-byte page or 2 256-byte pages. There is no check
for bad blocks or ECC errors.
nand write addr ofs|partition size
Write `size' bytes from `addr' to `ofs' in NAND flash. If a page
cannot be written because it is marked bad or the write fails the
command stops with an error.
nand write.jffs2 addr ofs|partition size
Like `write', but blocks that are marked bad are skipped and the
is written to the next block instead. This allows writing writing
a JFFS2 image, as long as the image is short enough to fit even
after skipping the bad blocks. Compact images, such as those
produced by mkfs.jffs2 should work well, but loading an image copied
from another flash is going to be trouble if there are any bad blocks.
nand write.oob addr ofs|partition size
Write `size' bytes from `addr' to the out-of-band data area
corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
of data for one 512-byte page or 2 256-byte pages. There is no check
for bad blocks.
Configuration Options:
CFG_CMD_NAND
A good one to add to CONFIG_COMMANDS since it enables NAND support.
CONFIG_MTD_NAND_ECC_JFFS2
Define this if you want the Error Correction Code information in
the out-of-band data to be formatted to match the JFFS2 file system.
CONFIG_MTD_NAND_ECC_YAFFS would be another useful choice for
someone to implement.
CFG_MAX_NAND_DEVICE
The maximum number of NAND devices you want to support.
NAND Interface:
#define NAND_WAIT_READY(nand)
Wait until the NAND flash is ready. Typically this would be a
loop waiting for the READY/BUSY line from the flash to indicate it
it is ready.
#define WRITE_NAND_COMMAND(d, adr)
Write the command byte `d' to the flash at `adr' with the
CLE (command latch enable) line true. If your board uses writes to
different addresses to control CLE and ALE, you can modify `adr'
to be the appropriate address here. If your board uses I/O registers
to control them, it is probably better to let NAND_CTL_SETCLE()
and company do it.
#define WRITE_NAND_ADDRESS(d, adr)
Write the address byte `d' to the flash at `adr' with the
ALE (address latch enable) line true. If your board uses writes to
different addresses to control CLE and ALE, you can modify `adr'
to be the appropriate address here. If your board uses I/O registers
to control them, it is probably better to let NAND_CTL_SETALE()
and company do it.
#define WRITE_NAND(d, adr)
Write the data byte `d' to the flash at `adr' with the
ALE and CLE lines false. If your board uses writes to
different addresses to control CLE and ALE, you can modify `adr'
to be the appropriate address here. If your board uses I/O registers
to control them, it is probably better to let NAND_CTL_CLRALE()
and company do it.
#define READ_NAND(adr)
Read a data byte from the flash at `adr' with the
ALE and CLE lines false. If your board uses reads from
different addresses to control CLE and ALE, you can modify `adr'
to be the appropriate address here. If your board uses I/O registers
to control them, it is probably better to let NAND_CTL_CLRALE()
and company do it.
#define NAND_DISABLE_CE(nand)
Set CE (Chip Enable) low to enable the NAND flash.
#define NAND_ENABLE_CE(nand)
Set CE (Chip Enable) high to disable the NAND flash.
#define NAND_CTL_CLRALE(nandptr)
Set ALE (address latch enable) low. If ALE control is handled by
WRITE_NAND_ADDRESS() this can be empty.
#define NAND_CTL_SETALE(nandptr)
Set ALE (address latch enable) high. If ALE control is handled by
WRITE_NAND_ADDRESS() this can be empty.
#define NAND_CTL_CLRCLE(nandptr)
Set CLE (command latch enable) low. If CLE control is handled by
WRITE_NAND_ADDRESS() this can be empty.
#define NAND_CTL_SETCLE(nandptr)
Set CLE (command latch enable) high. If CLE control is handled by
WRITE_NAND_ADDRESS() this can be empty.
More Definitions:
These definitions are needed in the board configuration for now, but
may really belong in a header file.
TODO: Figure which ones are truly configuration settings and rename
them to CFG_NAND_... and move the rest somewhere appropriate.
#define SECTORSIZE 512
#define ADDR_COLUMN 1
#define ADDR_PAGE 2
#define ADDR_COLUMN_PAGE 3
#define NAND_ChipID_UNKNOWN 0x00
#define NAND_MAX_FLOORS 1
#define NAND_MAX_CHIPS 1
NOTE:
=====
We now use a complete rewrite of the NAND code based on what is in
2.6.12 Linux kernel.
The old NAND handling code has been re-factored and is now confined
to only board-specific files and - unfortunately - to the DoC code
(see below). A new configuration variable has been introduced:
CFG_NAND_LEGACY, which has to be defined in the board config file if
that board uses legacy code. If CFG_NAND_LEGACY is defined, the board
specific config.mk file should also have "BOARDLIBS =
drivers/nand_legacy/libnand_legacy.a". For boards using the new NAND
approach (PPChameleon and netstar at the moment) no variable is
necessary, but the config.mk should have "BOARDLIBS =
drivers/nand/libnand.a".
The necessary changes have been made to all affected boards, and no
build breakage has been introduced, except for NETTA and NETTA_ISDN
targets from MAKEALL. This is due to the fact that these two boards
use JFFS, which has been adopted to use the new NAND, and at the same
time use NAND in legacy mode. The breakage will disappear when the
board-specific code is changed to the new NAND.
As mentioned above, the legacy code is still used by the DoC subsystem.
The consequence of this is that the legacy NAND can't be removed from
the tree until the DoC is ported to use the new NAND support (or boards
with DoC will break).
Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
JFFS2 related commands:
implement "nand erase clean" and old "nand erase"
using both the new code which is able to skip bad blocks
"nand erase clean" additionally writes JFFS2-cleanmarkers in the oob.
"nand write.jffs2"
like "nand write" but skip found bad eraseblocks
"nand read.jffs2"
like "nand read" but skip found bad eraseblocks
Miscellaneous and testing commands:
"markbad [offset]"
create an artificial bad block (for testing bad block handling)
"scrub [offset length]"
like "erase" but don't skip bad block. Instead erase them.
DANGEROUS!!! Factory set bad blocks will be lost. Use only
to remove artificial bad blocks created with the "markbad" command.
NAND locking command (for chips with active LOCKPRE pin)
"nand lock"
set NAND chip to lock state (all pages locked)
"nand lock tight"
set NAND chip to lock tight state (software can't change locking anymore)
"nand lock status"
displays current locking status of all pages
"nand unlock [offset] [size]"
unlock consecutive area (can be called multiple times for different areas)
I have tested the code with board containing 128MiB NAND large page chips
and 32MiB small page chips.

60
doc/README.nand-boot-ppc440
View File

@ -1,60 +0,0 @@
-----------------------------
NAND boot on PPC440 platforms
-----------------------------
This document describes the U-Boot NAND boot feature as it
is implemented for the AMCC Sequoia (PPC440EPx) board.
The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH,
completely without NOR FLASH. This can be done by using the NAND
boot feature of the 440 NAND flash controller (NDFC).
Here a short desciption of the different boot stages:
a) IPL (Initial Program Loader, integrated inside CPU)
------------------------------------------------------
Will load first 4k from NAND (SPL) into cache and execute it from there.
b) SPL (Secondary Program Loader)
---------------------------------
Will load special U-Boot version (NUB) from NAND and execute it. This SPL
has to fit into 4kByte. It sets up the CPU and configures the SDRAM
controller and the NAND controller so that the special U-Boot image can be
loaded from NAND to SDRAM.
This special image is build in the directory "nand_spl".
c) NUB (NAND U-Boot)
--------------------
This NAND U-Boot (NUB) is a special U-Boot version which can be started
from RAM. Therefore it mustn't (re-)configure the SDRAM controller.
On 440EPx the SPL is copied to internal SRAM before the NAND controller
is set up. While still running from cache, I experienced problems accessing
the NAND controller.
Example: Build and install NAND boot image for Sequoia (440EPx):
a) Configure for sequoia with NAND boot support:
# make sequoia_nand_config
b) Build image(s)
# make
This will generate the SPL image in the "nand_spl" directory:
nand_spl/u-boot-spl.bin
Also another image is created spanning a whole NAND block (16kBytes):
nand_spl/u-boot-spl-16k.bin
The main NAND U-Boot image is generated in the toplevel directory:
u-boot.bin
A combined image of u-boot-spl-16k.bin and u-boot.bin is also created:
u-boot-nand.bin
This image should be programmed at offset 0 in the NAND flash:
# tftp 100000 /tftpboot/sequoia/u-boot-nand.bin
# nand erase 0 60000
# nand write 100000 0 60000
September 07 2006, Stefan Roese <sr@denx.de>

38
doc/README.ne2000
View File

@ -1,38 +0,0 @@
This driver supports NE2000 compatible cards (those based on DP8390,
DP83902 and similar). It can be used with PCMCIA/CF cards provided
that the CCR is correctly initialized.
The code is based on sources from the Linux kernel (pcnet_cs.c,
8390.h) and eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2
wonderful world are GPL, so this is, of course, GPL.
I developed and tested this driver on a custom PXA255 based system and
with a billionton CF network card connected to the PCMCIA interface of
the micro (have a look at README.PXA_CF for the support of this port).
The options you have to specify in the config file are (with the
value for my board as an example):
#define CONFIG_DRIVER_NE2000
- Enables the driver
#define CONFIG_DRIVER_NE2000_BASE (0x20000000+0x300)
- Address where the board is mapped
#define CONFIG_DRIVER_NE2000_CCR (0x28000000+0x3f8)
- Address of the CCR (card configuration register). It could be found
by enabling DEBUG in cmd_pcmcia.c. If this is not defined nothing is
done as far as PCMCIA support is concerned.
#define CONFIG_DRIVER_NE2000_VAL (0x20)
- The value to be written in the CCR. It selects among different I/O
spaces that could be used by the card.
Enjoy!
Christian Pellegrin <chri@ascensit.com>

366
doc/README.nios
View File

@ -1,366 +0,0 @@
U-Boot for Nios-32
Last Update: February 1, 2004
====================================================================
This file contains information regarding U-Boot and the Altera
Nios CPU. For information regarding U-Boot and the Nios Development
Kits see:
* Cyclone Edition (DK-1C20), see doc/README.dk1c20
* Stratix Edition (DK-1S10), see doc/README.dk1s10 (TODO)
* Stratix Edition (DK-1S40), see doc/README.dk1s40 (TODO)
* Stratix Edition (DK-20K200), see doc/README.dk20k200 (TODO)
For informations regarding Nios Development Kit hardware overview
and the NIOS CPU standard configuration of all known boards made by
Altera see:
* Development Kit (DK) hardware overview, see doc/README.nios_DK
* NIOS CPU standard_32 at DK-1C20, see doc/README.dk1c20_std32
* NIOS CPU standard_32 at DK-1S10, see doc/README.dk1s10_std32
* NIOS CPU standard_32 at DK-1S40, see doc/README.dk1s40_std32
* NIOS CPU standard_32 at DK-20K200, see doc/README.dk20k200_std32
For those interested in contributing ... see HELP WANTED below.
1. OVERVIEW
------------
U-Boot has been successfully tested on the Nios Cyclone development
board using both the 'safe' and 'standard 32' configurations with
Nios CPU revision 3.1 (CPU_ID = 0x3018). U-Boot can be used with
or without the GERMS monitor. The initial version of U-Boot for the
Cyclone development kit is about 60 Kbyte and will fit in a single
sector of on-board FLASH. Only the Nios 32-bit CPU is supported.
1.1 GERMS Monitor
------------------
If GERMS is just not enough, then U-Boot is a great antibiotic.
You will be very pleased with its high degree of configurability
and its rich feature set.
A few of the most obvious limitations of GERMS are overcome by
using U-Boot (See 'Brain Damage'). Most notably, you can use
minicom or Hyperterminal (duh).
1.2 Altera Source Code
-----------------------
The Nios port does NOT include ANY sources that Altera has the
copyright. This was a conscious decision ... not an accident.
The Altera license is not clear in terms of distributing Altera
sources (when altera silicon is not involved). This isn't really
a problem as little, if any, of the Altera source contains
features that are not already available in U-Boot.
1.3 Debugging via OCI
---------------------
The Nios port supports debugging with gdb and/or nios-console
via the JTAG port. Stubs for debugging with gdb via the serial
port are not currently implemented.
2. CONFIGURATION OPTIONS/SETTINGS
----------------------------------
2.1 Nios-specific Options/Settings
-----------------------------------
All configuration options/settings that are specific to Nios begin
with "CONFIG_NIOS_", "CFG_NIOS_", or "CFG_NIOS_CPU_".
The configuration follows a two-stage process. In the first stage
the NIOS CPU core will defined like defined in Alteras SOPC Builder.
At this point we use the "CFG_NIOS_CPU_" defines exclusively. For
more informations about all the definitions you have to setup see
into current board configurations and doc/README.nios_CFG_NIOS_CPU.
In second stage we bring the NIOS CPU configuration in relation to
U-Boot configuration options/settings. The following is a list of
currently defined Nios-specific options/parameters used inside of
U-Boot. If any options are related to Standard-32 Nios SDK
excalibur.h definitions, the related definition follows the
description).
CONFIG_NIOS -- defined for all Nios-32 boards.
CFG_NIOS_CONSOLE -- the base address of the console UART or the JTAG
stdio port. To enable a console via JTAG, define
CONFIG_CONSOLE_JTAG and set CGF_NIOS_CONSOLE to the base address
of the JTAG stdio port (normally OCI base + 0x00fa). Then
run nios-console with the -w option.
(standard-32: nasys_uart_0 resp. na_uart1_base).
CFG_NIOS_FIXEDBAUD -- defined if the console UART PTF fixed_baud
parameter is set to '1'.
CFG_NIOS_MULT_HW -- use full hardware multiply (not yet implemented).
CFG_NIOS_MULT_MSTEP -- use hardware assisted multiply using the
MSTEP instruction (not yet implemented).
CFG_NIOS_TMRBASE -- the base address of the timer used to support
xxx_timer routines (e.g. set_timer(), get_timer(), etc.).
(standard-32: nasys_timer_1 resp. na_lo_priority_timer2_base).
CFG_NIOS_TMRIRQ -- the interrupt request (vector number) assigned to
the timer. (standard-32: nasys_timer_1_irq resp.
na_low_priority_timer2_irq).
CFG_NIOS_TMRMS -- the period of the timer in milliseconds.
CFG_NIOS_TMRCNT -- the preloadable counter value for the timer if it has
no fixed period.
CFG_NIOS_ASMIBASE -- the base address of the ASMI peripheral.
(standard-32: na_asmi_base).
CFG_NIOS_SPIBASE -- the base address of the SPI master (!) peripheral.
(nasys_spi_0)
CFG_NIOS_SPIBITS -- the amount of configured SPI data bits in PTF.
This value can be 8 or 16 only! (PTF: databits)
2.2 Differences in U-Boot Options/Settings
-------------------------------------------
Some 'standard' U-Boot options/settings are treated differently in
the Nios port. These are described below.
CFG_GBL_DATA_OFFSET -- in the Nios port, this is the offset of the
global data structure in the Nios memory space. More simply,
the address of global data.
3. ASSEMBLY CODING
-------------------
In browsing the assembly source files, you may notice the absence
of the 'magic macros' (e.g. MOVIA, MOVIP, ADDIP etc.). This is
deliberate. The documentation for the magic macros is scant and
it is hard to find ... it does not appear in the Nios programmer's
manual, nor does it appear in the assembler manual. Regardless,
the macros actually do very little to improve readability anyway.
With this in mind, all assembler modules use only instructions that
appear in the Nios programmer's manual OR are directly supported
by the nios-elf toolchain. For example, the 'dec %rB' instruction
is an alias for 'subi %rB,1' that is supported by the assembler
but does not appear in the programmer's manual.
4. BOOT PROCESS
---------------
4.1 Boot process over GERMS
---------------------------
When the NIOS CPU catch a reset signal it will begin to be running
code from CFG_NIOS_CPU_RST_VECT. Normally at this place it will
find the GERMS monitor. That's the case for the generic NIOS CPU
configuration "standard_32". When the GERMS monitor starts running,
it performs important system initializations and then looks for
executable code in flash, using the following steps:
1. Examining the two bytes at CFG_NIOS_CPU_FLASH_BASE + 0x04000C.
2. Examining the button 0 on the PIO CFG_NIOS_CPU_BUTTON_PIO.
3. If the button is not pressed and the two bytes contain 'N'
and 'i', the monitor executes a CALL to location
CFG_NIOS_CPU_FLASH_BASE + 0x040000.
4. If the code is not executed in step 3 or the code returns,
then prints an 8-digit version number to STDOUT and waits for
user commands from STDIN.
In normal case, for "standard_32", STDIN and STDOUT are the first
serial port.
4.2 Return to GERMS command line
--------------------------------
During the boot process, the GERMS monitor checks for the existence
of application software in flash memory. If found, the processor
immediately executes the code. To return program execution to the
GERMS monitor (that is, avoid running code stored in flash memory):
1. Hold down CFG_NIOS_CPU_BUTTON_PIO, button number 0.
2. Press then release the CPU reset button.
3. Release CFG_NIOS_CPU_BUTTON_PIO, button number 0.
5. DEBUGGING WITH GDB
---------------------
Debug sessions using gdb are currently supported only via JTAG. The
stubs for debugging via a serial port are not implemented. To enable
the gdb JTAG stubs, simply reference _brkpt_hw_int and _brkpt_sw_int
at vector table offsets 3 and 4, respectively. For an example, see
board/altera/dk1c20/vectors.S.
5.1 Vector Table Initialization and ROM Stubs
---------------------------------------------
If CONFIG_ROM_STUBS is defined, the debug breakpoint and single step
entries in the vector table are restored to their initial values
immediately _after_ initializing the vector table. Defining this macro
is useful when ROM-based stubs are implemented.
NOTE: The default GERMS monitor does NOT implement gdb stubs, nor does
it initialize the vector table. Therefore, when debugging U-Boot, you
should NOT set a software breakpoint prior to vector table initialization.
5.2 Starting a Debug Session
----------------------------
If you're not familiar with gdb, you follow these step-by-step instructions.
These instructions are NOT the only way to start a debug session, but they
cover most of the individual functions to get you started.
1. Start the JTAG gdb server. Open a Nios shell window and start
the server. When the server is started you must provide the base
address of the OCI core. For example, when using the Cyclone
development kit (DK1C20):
$ nios-gdb-server --ocibase=0x00920800 --tcpport=2342
2. Start gdb. Open a Nios shell window, change to the top-level
U-Boot directory and start gdb, specifying the u-boot elf file:
$ nios-elf-gdb u-boot
3. Update target settings. From the file menu, select
"Target Settings ..." and select the following, then click 'Ok':
Target: Remote/TCP
Port : 2342 (same as in step 1)
Display download dialog: checked
All other check boxes: unchecked
4. Connect to the target. Select menu: 'Run->Connect to target'.
You should see a dialog box indicating the you successfully connected
to the target.
5. Download U-Boot. Select menu: 'Run->Download'.
6. Open a gdb console window and set the source directory paths.
Select menu: 'View->Console'. In the console window, enter the
following commands, then close the console window:
(gdb) directory common
(gdb) directory cpu/nios
(gdb) directory lib_nios
(gdb) directory board/altera/dk1c20
Note that the last command is for the DK1C20 board only. If you
are using another board, specify that board's directory.
7. Open the file board.c (using the file menu in the lower
left hand corner). Scroll to the board_init() routine and set
a breakpoint.
8. Run U-Boot. Just click on the run icon, or select menu:
'Run->Run'. U-Boot should start running, then break at your
breakpoint.
9. Have fun & start learning more about gdb.
5.3 For advanced Users
----------------------
A few notes for those more familiar with gdb.
-Serial port stubs are not implemented. Sorry, but it's just not
worth _my_ effort. The JTAG stubs work great and are ridiculously
simple to implement.
-If you need to debug the early startup code (prior to the vector
table initialization), use the nios-console debugger.
- Connect, download & run -- there are some problems here. Connect
download and run seperately to avoid trouble.
6. BRAIN DAMAGE
----------------
This section describes some of the unfortunate and avoidable aspects
of working with the Nios CPU ... and some things you can do to
reduce your pain.
6.1 GERMS doesn't work with Hyperterminal
------------------------------------------
GERMS doesn't do CR/LF mapping that is compatible with Hyperterminal
(or minicom) -- geez. Regardless of you opion of Hyperterminal, this
sad design decision is remedied by using U-Boot.
6.2 cygwin Incompatibility
---------------------------
The version of cygwin distributed with the nios GNUPro toolchain is
out-of-date and incompatible with the latest cygwin distributions.
In addition, many of the standard utilities are very dated as well.
If you try to download and build the lastest version of grep for
example, you'll quickly realize that a native gcc is not available
(the next topic) which leads to U-Boot build problems (following
topic).
The solution ... well, you can wait for Altera ... or build as
set of tools for linux.
6.3 No native gcc
------------------
I'm not sure how this one slipped through the cracks ... but it is
a real pain. Basically, if you want to build anything for the native
environment -- forget it! A native (cygwin) gcc is not distributed,
and the old version of cygwin makes locating one challenging.
The solution ... same as above. Just download the gcc source from
Altera and build up a set of cross tools for your favorite linux
distro. Anybody who wants to use an already precompiled NIOS cross
toolchain can it found in the CDK4NIOS project hosted by Source
Forge at http://cdk4nios.sourceforge.net.
6.4 Can't build default U-Boot
-------------------------------
By default, when you build U-Boot you will be building some native
tools along with the target elf, bin, and srec files. Without a
native gcc, this (obviously) causes problems.
For developers using the Altera cygwin tools you can remove the
'tools' directory from SUBDIRS in the top-level Makefile. You will
also have to edit common/Makefile:
Replace:
environment.o: environment.c ../tools/envcrc
$(CC) $(AFLAGS) -Wa,--no-warn \
-DENV_CRC=$(shell ../tools/envcrc) \
-c -o $@ environment.c
With:
environment.o: environment.c
$(CC) $(AFLAGS) -Wa,--no-warn \
-DENV_CRC=0 \
-c -o $@ environment.c
BTW, thats a 'zero' ... not the letter 'O'. And not that the
"../tools/envcrc" dependency is removed.
7. HELP WANTED
---------------
There are plenty of areas where help is needed. Here's are some ideas
for those interested in contributing:
-CompactFlash. Port & test CF/FAT.
-Bedbug. Develop bedbug for Nios ... or at least provide a disassemble
command.
-Add boot support for ucLinux (niosnommu).
-Implement (don't copy Altera code) the __mulxx routines using the
MSTEP and MUL instructions (e.g. CFG_NIOS_MULT_HW and CFG_NIOS_MULT_MSTEP).
Regards,
--Scott
<smcnutt@psyent.com>
--Stephan
<linz@li-pro.net>

140
doc/README.nios_CFG_NIOS_CPU
View File

@ -1,140 +0,0 @@
===============================================================================
C F G _ N I O S _ C P U _ * v s . N I O S S D K
===============================================================================
When ever you have to make a new NIOS CPU configuration you can use this table
as a reference list to the original NIOS SDK symbols made by Alteras SOPC
Builder. Look into excalibur.h and excalibur.s in your SDK path cpu_sdk/inc.
Symbols beginning with a '[ptf]:' are coming from your SOPC sytem description
(PTF file) in sections WIZARD_SCRIPT_ARGUMENTS or SYSTEM_BUILDER_INFO.
C O R E N I O S S D K [1],[7]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_CLK nasys_clock_freq
CFG_NIOS_CPU_ICACHE nasys_icache_size
CFG_NIOS_CPU_DCACHE nasys_dcache_size
CFG_NIOS_CPU_REG_NUMS nasys_nios_num_regs
CFG_NIOS_CPU_MUL __nios_use_multiply__
CFG_NIOS_CPU_MSTEP __nios_use_mstep__
CFG_NIOS_CPU_STACK nasys_stack_top
CFG_NIOS_CPU_VEC_BASE nasys_vector_table
CFG_NIOS_CPU_VEC_SIZE nasys_vector_table_size
CFG_NIOS_CPU_VEC_NUMS
CFG_NIOS_CPU_RST_VECT nasys_reset_address
CFG_NIOS_CPU_DBG_CORE nasys_debug_core
CFG_NIOS_CPU_RAM_BASE na_onchip_ram_64_kbytes
CFG_NIOS_CPU_RAM_SIZE na_onchip_ram_64_kbytes_size
CFG_NIOS_CPU_ROM_BASE na_boot_monitor_rom
CFG_NIOS_CPU_ROM_SIZE na_boot_monitor_rom_size
CFG_NIOS_CPU_OCI_BASE nasys_oci_core
CFG_NIOS_CPU_OCI_SIZE
CFG_NIOS_CPU_SRAM_BASE na_ext_ram nasys_program_mem
nasys_data_mem
CFG_NIOS_CPU_SRAM_SIZE na_ext_ram_size nasys_program_mem_size
nasys_data_mem_size
CFG_NIOS_CPU_SDRAM_BASE na_sdram
CFG_NIOS_CPU_SDRAM_SIZE na_sdram_size
CFG_NIOS_CPU_FLASH_BASE na_ext_flash nasys_main_flash
nasys_am29lv065d_flash_0
nasys_flash_0
CFG_NIOS_CPU_FLASH_SIZE na_ext_flash_size nasys_main_flash_size
T I M E R N I O S S D K [3]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_TIMER_NUMS nasys_timer_count
CFG_NIOS_CPU_TIMER[0-9] nasys_timer_[0-9]
CFG_NIOS_CPU_TIMER[0-9]_IRQ nasys_timer_[0-9]_irq
CFG_NIOS_CPU_TIMER[0-9]_PER [ptf]:period
[ptf]:period_units
[ptf]:mult
CFG_NIOS_CPU_TIMER[0-9]_AR [ptf]:always_run
CFG_NIOS_CPU_TIMER[0-9]_FP [ptf]:fixed_period
CFG_NIOS_CPU_TIMER[0-9]_SS [ptf]:snapshot
U A R T N I O S S D K [2]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_UART_NUMS nasys_uart_count
CFG_NIOS_CPU_UART[0-9] nasys_uart_[0-9]
CFG_NIOS_CPU_UART[0-9]_IRQ nasys_uart_[0-9]_irq
CFG_NIOS_CPU_UART[0-9]_BR [ptf]:baud
CFG_NIOS_CPU_UART[0-9]_DB [ptf]:data_bits
CFG_NIOS_CPU_UART[0-9]_SB [ptf]:stop_bits
CFG_NIOS_CPU_UART[0-9]_PA [ptf]:parity
CFG_NIOS_CPU_UART[0-9]_HS [ptf]:use_cts_rts
CFG_NIOS_CPU_UART[0-9]_EOP [ptf]:use_eop_register
P I O N I O S S D K [4]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_PIO_NUMS nasys_pio_count
CFG_NIOS_CPU_PIO[0-9] nasys_pio_[0-9]
CFG_NIOS_CPU_PIO[0-9]_IRQ nasys_pio_[0-9]_irq
CFG_NIOS_CPU_PIO[0-9]_BITS [ptf]:Data_Width
CFG_NIOS_CPU_PIO[0-9]_TYPE [ptf]:has_tri
[ptf]:has_out
[ptf]:has_in
CFG_NIOS_CPU_PIO[0-9]_CAP [ptf]:capture
CFG_NIOS_CPU_PIO[0-9]_EDGE [ptf]:edge_type
CFG_NIOS_CPU_PIO[0-9]_ITYPE [ptf]:irq_type
S P I N I O S S D K [6]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_SPI_NUMS nasys_spi_count
CFG_NIOS_CPU_SPI[0-9] nasys_spi_[0-9]
CFG_NIOS_CPU_SPI[0-9]_IRQ nasys_spi_[0-9]_irq
CFG_NIOS_CPU_SPI[0-9]_BITS [ptf]:databits
CFG_NIOS_CPU_SPI[0-9]_MA [ptf]:ismaster
CFG_NIOS_CPU_SPI[0-9]_SLN [ptf]:numslaves
CFG_NIOS_CPU_SPI[0-9]_TCLK [ptf]:targetclock
CFG_NIOS_CPU_SPI[0-9]_TDELAY [ptf]:targetdelay
CFG_NIOS_CPU_SPI[0-9]_* [ptf]:*
I D E N I O S S D K
-------------------------------------------------------------------------------
CFG_NIOS_CPU_IDE_NUMS nasys_usersocket_count
CFG_NIOS_CPU_IDE[0-9] nasys_usersocket_[0-9]
A S M I N I O S S D K [5]
-------------------------------------------------------------------------------
CFG_NIOS_CPU_ASMI_NUMS nasys_asmi_count
CFG_NIOS_CPU_ASMI[0-9] nasys_asmi_[0-9]
CFG_NIOS_CPU_ASMI[0-9]_IRQ nasys_asmi_[0-9]_irq
E t h e r n e t ( L A N ) N I O S S D K
-------------------------------------------------------------------------------
CFG_NIOS_CPU_LAN_NUMS
CFG_NIOS_CPU_LAN[0-9]_BASE na_lan91c111
CFG_NIOS_CPU_LAN[0-9]_OFFS LAN91C111_REGISTERS_OFFSET
CFG_NIOS_CPU_LAN[0-9]_IRQ na_lan91c111_irq
CFG_NIOS_CPU_LAN[0-9]_BUSW LAN91C111_DATA_BUS_WIDTH
CFG_NIOS_CPU_LAN[0-9]_TYPE
s y s t e m c o m p o s i n g N I O S S D K
-------------------------------------------------------------------------------
CFG_NIOS_CPU_TICK_TIMER (na_low_priority_timer2)
CFG_NIOS_CPU_USER_TIMER (na_timer1)
CFG_NIOS_CPU_BUTTON_PIO (na_button_pio)
CFG_NIOS_CPU_LCD_PIO (na_lcd_pio)
CFG_NIOS_CPU_LED_PIO (na_led_pio)
CFG_NIOS_CPU_SEVENSEG_PIO (na_seven_seg_pio)
CFG_NIOS_CPU_RECONF_PIO (na_reconfig_request_pio)
CFG_NIOS_CPU_CFPRESENT_PIO (na_cf_present_pio)
CFG_NIOS_CPU_CFPOWER_PIO (na_cf_power_pio)
CFG_NIOS_CPU_CFATASEL_PIO (na_cf_ata_select_pio)
CFG_NIOS_CPU_USER_SPI (na_spi)
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/ds/ds_nioscpu.pdf
[2] http://www.altera.com/literature/ds/ds_nios_uart.pdf
[3] http://www.altera.com/literature/ds/ds_nios_timer.pdf
[4] http://www.altera.com/literature/ds/ds_nios_pio.pdf
[5] http://www.altera.com/literature/ds/ds_nios_asmi.pdf
[6] http://www.altera.com/literature/ds/ds_nios_spi.pdf
[7] http://www.altera.com/literature/ds/ds_legacy_sdram_ctrl.pdf
===============================================================================
Stephan Linz <linz@li-pro.net>

192
doc/README.nios_DK
View File

@ -1,192 +0,0 @@
===============================================================================
H A R D W A R E O V E R V I E W
===============================================================================
===============|===============|===============|===============|===============
| DK20K200 | DK1C20 | DK1S10 | DK1S40
---------------|---------------|---------------|---------------|---------------
| | | |
Schem. Nr. | Nios Dev.Brd. | P06-08713-00 | P06-08468-01 | P06-09178-00
Rev. | pilot. | 01 | 01 | 00
Date | 2001/02/06 | 2003/02/20 | 2003/02/14 | 2003/05/14
[1] | | | |
===============|===============|===============|===============|===============
| | | |
FPGA | "APEX" | "Cyclon" | "Stratix" | "Stratix"
| EP20K200E | EP1C20 | EP1S10 | EP1S40
| | |
| (484 FBGA) | (400 FBGA) | (780 FBGA)
[2],[3],[4] | | |
---------------|---------------|---------------|---------------|---------------
| |
Clock (OSC) | 33.333 MHz | 50 MHz
| | (with ext. supply)
|
| PI49FCT3805
[5] |
---------------|---------------|---------------|---------------|---------------
| |
Flash | 1 MByte | 8 MByte
| |
| AM29LV800BB | AM29LV065DU120REI
| 8/16 bit bus | 8 bit bus
| 1 chip | 1 chip
[6],[7] | |
---------------|---------------|---------------|---------------|---------------
| | |
serial | no such | 4 MBits | no such
Flash | | |
| | EPCS4SI8 |
[8] | | |
---------------|---------------|---------------|---------------|---------------
| |
Compact | no such, as | see below: prototype adapter
Flash (CF) | module only |
| |
---------------|---------------|---------------|---------------|---------------
| |
SRAM | 256 KByte | 1 MByte
| |
| IDT71V016S | IDT71V416S10PH
| 32 bit bus | 32 bit bus
| 2 chips | 2 chips
| interlaced | interlaced
[9],[10] | |
---------------|---------------|---------------|---------------|---------------
| |
SDRAM | SODIMM only | 16 MByte
| |
| | MT48LC4M32B2TG-7
| 64 bit bus | 32 bit bus
| | 1 chip
[11] | |
===============|===============|===============|===============|===============
| |
serial I/O | 1 RS232 | 2 RS232
| |
| LTC1386 | MAX3237CAI
| |
| port 1: | port 1:
| RxD / TxD, | RxD / TxD,
| RTS / CTS | RTS / CTS, DTR / DSR, DCD, RI
| |
| ! ! ! ! ! ! | port 2: | port 2:
| RTS/CTS can | RxD / TxD | RxD / TxD
| be RxD/TxD | | RTS / CTS, DTR / DSR
| of 2nd port | | DCD, RI
[12],[13] | ! ! ! ! ! ! | |
---------------|---------------|---------------|---------------|---------------
| |
Ethernet | no such, as | 1 10BaseT / 100BaseT
| module only |
| | LAN91C111-NE
| | 32 bit bus
| | no external EEPROM
| | LEDA# for link
| | LEDB# for Rx / Tx
[14] | |
===============|===============|===============|===============|===============
| |
user | 8 | no such
switches | SW[7..0] |
| |
---------------|---------------|---------------|---------------|---------------
|
user push | 4
buttons | PB[3..0]
|
---------------|---------------|---------------|---------------|---------------
| |
user LEDs | 2 | 8
| LED[1..0] | LED[7..0]
| |
---------------|---------------|---------------|---------------|---------------
|
user seven | 2
segment | HEX[1..0][G..A,DP]
|
===============|===============|===============|===============|===============
| |
3.3V proto- | w/o level | no such -- only 5V
type adapter | shift buffer |
| |
| 40 I/O pins |
| 1 card sel. |
| 1 reset out. |
| 1 OSC clock |
| 1 CPU clock |
| 1 clock out. |
| |
---------------|---------------|---------------|---------------|---------------
| |
5V prototype | with level | 2 ports -- both card ports supplied with its
adapter | shift buffer | own level shift buffer
| |
| 40 I/O pins | port 1 & 2:
| 1 card sel. | 41 I/O pins
| 1 Vee ? ? ? | 1 card select
| 1 reset out. | 1 reset output (from dev/board)
| 1 OSC clock | 1 OSC clock (from dev/board)
| 1 CPU clock | 1 CPU clock (from dev/board)
| 1 clock inp. | 1 clock input (to dev/board)
| |
| | (special) port 1:
| | 1 CF select
| | 1 CF present
| | 1 CF ATA select
| | 1 CF power
| |
| | NOTE: Both card ports are prepared for raw
| | IDE working. You can connect such
| | devices directly to the 40 pin header.
| | The signal PDIAG (passed diagnostic)
| | is not connected to any I/O signal.
| | Card port 1 is hard wired to the on
| | board Copact Flash adapter together
| | with all other signals needed by CF
| | cards. Hot plug should be working too.
[15],[16] | |
===============|===============|===============|===============|===============
| |
config. CPLD | EPM7064 | EPM7128
| |
(alternative | decition by | decision by
FPGA conf.) | jumper | push button
| |
| FPGA config. | FPGA config. | FPGA config.
| from Flash | from Flash | from Flash
| only | and EPCS4 | only
| | |
===============|===============|===============|===============|===============
===============================================================================
===============================================================================
R E F E R E N C E S
===============================================================================
[1] http://www.altera.com/literature/lit-nio.jsp
[2] http://www.altera.com/literature/lit-apx.jsp
[3] http://www.altera.com/literature/lit-cyc.jsp
[4] http://www.altera.com/literature/lit-stx.jsp
[5] http://www.pericom.com/pdf/datasheets/PI49FCT3805.pdf
http://www.pericom.com/products/clock/psempart.php?productID=PI49FCT3805
[6] http://www.amd.com/us-en/FlashMemory/ProductInformation/0,,37_1447_1623_1468^1532,00.html
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/21490.pdf
[7] http://www.amd.com/us-en/FlashMemory/ProductInformation/0,,37_1447_1623_1468^1596,00.html
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23544b.pdf
[8] http://www.altera.com/literature/lit-config.html
http://preview.altera.com/literature/ds/micron.pdf
[9] http://www.idt.com/products/pages/Asynchronous_SRAMs-71V016SA.html
[10] http://www.idt.com/products/pages/Asynchronous_SRAMs-71V416SL.html
[11] http://www.micron.com/products/dram/sdram/part.aspx?part=MT48LC4M32B2TG-7
[12] http://www.linear.com/prod/datasheet.html?datasheet=33
http://www.linear.com/pdf/1386fa.pdf
[13] http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1068/ln/en
http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf
[14] http://www.smsc.com/main/catalog/lan91c111.html
[15] http://www.t13.org/index.html
[16] http://www.compactflash.org/faqs/faq.htm
===============================================================================
Stephan Linz <linz@li-pro.net>

36
doc/README.ns9750dev
View File

@ -1,36 +0,0 @@
U-Boot Port to the NS9750 DevKit from NetSilicon
1 Overview
2 Board Configuration
3 Installation
1 Overview
----------
This port supports these NS9750 features.
o one UART
2 Board Configuration
---------------------
Switches:
SW10: 4
SW11: 6,7
SW16: 6,7,8
SW17-SW20: 1
SW4: 3, 6
SW 1: 1
SW2: 4
SW3: 3
SW8: 3 (rotated by 180 degree!!!!)
Serial Console is Port B (bottom right port)
3 Installation
--------------
Have fun,
--
Markus Pietrek <mpietrek@fsforth.de>

73
doc/README.ocotea
View File

@ -1,73 +0,0 @@
AMCC Ocotea Board
Last Update: March 2, 2004
=======================================================================
This file contains some handy info regarding U-Boot and the AMCC
Ocotea 440gx evalutation board. See the README.ppc440 for additional
information.
SWITCH SETTINGS & JUMPERS
==========================
Here's what I've been using successfully. If you feel inclined to
change things ... please read the docs!
DIPSW U46 U80
------------------------
SW 1 off off
SW 2 on off
SW 3 off off
SW 4 off off
SW 5 off off
SW 6 on on
SW 7 on off
SW 8 on off
J41: strapped
J42: open
All others are factory default.
I2C Information
=====================
See README.ebony for information.
PCI
===========================
Untested at the time of writing.
PPC440GX Ethernet EMACs
===========================
All EMAC ports have been tested and are known to work
with EPS Group 4.
Special note about the Cicada CIS8201:
The CIS8201 Gigabit PHY comes up in GMII mode by default.
One must hit an extended register to allow use of RGMII mode.
This has been done in the 440gx_enet.c file with a #ifdef/endif
pair.
AMCC does not store the EMAC ethernet addresses within their PIBS bootloader.
The addresses contained in the config header file are from my particular
board and you _*should*_ change them to reflect your board either in the
config file and/or in your environment variables. I found the addresses on
labels on the bottom side of the board.
BDI2k or JTAG Debugging
===========================
For ease of debugging you can swap the small boot flash and external SRAM
by changing U46:3 to on. You can then use the sram as your boot flash by
loading the sram via the jtag debugger.
Regards,
--Travis
<tsawyer@sandburst.com>

99
doc/README.ocotea-PIBS-to-U-Boot
View File

@ -1,99 +0,0 @@
------------------------------------------
Installation of U-Boot using PIBS firmware
------------------------------------------
This document describes how to install U-Boot on the Ocotea PPC440GX
Evaluation Board. We do not erase the PIBS firmware but install U-Boot in the
soldered FLASH. After this you should be able to switch between PIBS and
U-Boot via the switch U46 SW1. Please check that SW1 is off (= open) before
continuing.
Connect to the serial port 0 (J11 lower) of the Ocotea board using the cu
program. See the hints for configuring cu above. Make sure you can
communicate with the PIBS firmware: reset the board and hit ENTER a couple of
times until you see the PIBS prompt (PIBS $). Then proceed as follows:
Read MAC Addresses from PIBS
----------------------------
To read the configured MAC addresses available on your Ocotea board please use
the following commands:
PIBS $ echo $hwdaddr0
000173017FE3
PIBS $ echo $hwdaddr1
000173017FE4
PIBS $ echo $hwdaddr2
000173017FE1
PIBS $ echo $hwdaddr3
000173017FE2
In U-Boot this is stored in the following environment variables:
* Ethernet Address 0: ethaddr = 000173017FE3 (==> 00:01:73:01:7F:E3)
* Ethernet Address 1: eth1addr = 000173017FE4 (==> 00:01:73:01:7F:E4)
* Ethernet Address 2: eth2addr = 000173017FE1 (==> 00:01:73:01:7F:E1)
* Ethernet Address 3: eth3addr = 000173017FE2 (==> 00:01:73:01:7F:E2)
Configure the network interface (ent0 == emac0)
-----------------------------------------------
To download the U-Boot image we need to configure the ethernet interface with
the following commands:
PIBS $ ifconfig ent0 192.168.160.142 netmask 255.255.0.0 up
PIBS $ set ipdstaddr0=192.168.1.1
status: writing PIBS variable value to FLASH
PIBS $ set bootfilename=/tftpboot/ocotea/u-boot.bin
status: writing PIBS variable value to FLASH
Please insert correct parameters for your configuration (ip-addresses and
file-location).
Program U-Boot into soldered User-FLASH
---------------------------------------
Please make sure to use a newer version of U-Boot (at least 1.1.3), since
older versions don't support running from user-FLASH.
To program U-Boot into the soldered user-FLASH use the following command:
PIBS $ storefile bin eth 0xffbc0000
This commands loads the file vis ethernet into ram and copies it into the
user-FLASH.
Switch to U-Boot
----------------
Now you can turn your board off and switch SW1 (U46) to on (= closed). After
powering the board you should see the following message:
U-Boot 1.1.3 (Apr 5 2005 - 22:59:57)
AMCC PowerPC 440 GX Rev. C
Board: AMCC 440GX Evaluation Board
VCO: 1066 MHz
CPU: 533 MHz
PLB: 152 MHz
OPB: 76 MHz
EPB: 76 MHz
I2C: ready
DRAM: 256 MB
FLASH: 5 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
KGDB: kgdb ready
ready
Net: ppc_440x_eth0, ppc_440x_eth1, ppc_440x_eth2, ppc_440x_eth3
BEDBUG:ready
=>
April 06 2005, Stefan Roese <sr@denx.de>

91
doc/README.omap730p2
View File

@ -1,91 +0,0 @@
u-boot for the TI OMAP730 Perseus2
Dave Peverley, MPC-Data Limited
http://www.mpc-data.co.uk
Overview :
As the OMAP730 is similar to the OMAP1610 in many ways, this port was based
on the u-boot port to the OMAP1610 Innovator. Supported features are :
- Serial terminal support
- Onboard NOR Flash
- Ethernet via the seperate debug board
- Tested on Rev4 and Rev5 boards
It has also been tested to work correctly when built with a 'standard' GCC
3.2.1 cross-compiler as well as Montavista Linux CEE 3.1's toolchain.
Hardware Configuration :
The main dips on the P2 board should be set to 2,3,7 and 9 on with all
others off. On the debug board, dips 1 and 7 should be on with the rest off.
The serial console has been set up to run from the DB9 connector on the
P2 board at 115200 baud, 8 data bits, no stop bits, 1 parity bit.
It should be noted that the P2 board has NOR flash that is addressable via
either CS0 or CS3. This mode can be changed via DIP9 on the P2 board.
Installing u-boot for the P2 :
You can simply build u-boot for the Perseus by following the instructions
in the main readme file. The target configuration is "omap730p2_config".
Once u-boot has been built, you should strip the executable so it can be
loaded via CCS (which cant cope with the symbols in the ELF binary) :
$ cp u-boot u-boot.out
$ arm-linux-strip u-boot.out
The method we've used for installing u-boot the first time on a P2 is
as follows :
1) Configure TI Code Composer Studio to connect to the P2 board via JTAG
as described in the Users Guide.
2) Set up the P2 to boot from CS3, and connect with CCS. Reset the CPU
and run the "init_mmu" GEL script.
3) Use the "Load Program" option to send the u-boot.out file to the P2 and
run.
At this point, u-boot should run and you will see the boot menu on your
serial terminal. You can then load the u-boot image to memory :
# loadb 0x10000000
Send the "u-boot.bin" binary via the serial using Kermit. Once loaded
you can self-flash u-boot :
# protect off 1:0
# erase 1:0
# cp.b 0x10000000 0x0 0x20000
You should now be able to reset the board and run u-boot from flash.
Alternative flash option :
Sometimes, if you've been silly, you can get the board into a state where
whats in flash has upset the board so much that you can no longer connect
to the P2 via JTAG. However, you can set DIP9 to off to swap the boot mode
of the P2 so that you boot from RAM instead of NOR flash. This moves NOR
flash up to 0x0C000000. You can build a special version of u-boot to
utilise this by the following config :
$ make omap730p2_cs0boot_config
If you load this up via CCS it will detect flash at its alternate location
and allow you to programme your u-boot image (which, remember must be built
for CS3 boot!) Once you do this, you can revert to CS3 boot and it will work
fine again.
Errata :
1) It's been observed that sometimes the tftp transfer of kernels to the
board can have checksum errors or stall. This appears to be an issue
with the lan91c96.c driver, and can normally be worked around by
resetting the board and trying again.

202
doc/README.ppc440
View File

@ -1,202 +0,0 @@
PowerPC 440
Last Update: September 11, 2002
=======================================================================
OVERVIEW
============
Support for the ppc440 is contained in the cpu/ppc44x directory
and enabled via the CONFIG_440 flag. It is largely based on the
405gp code. A sample board support implementation is contained
in the board/ebony directory.
All testing was performed using the AMCC Ebony board using both
Rev B and Rev C silicon. However, since the Rev B. silicon has
extensive errata, support for Rev B. is minimal (it boots, and
features such as i2c, pci, tftpboot, etc. seem to work ok).
The expectation is that all new board designs will be using
Rev C or later parts -- if not, you may be in for a rough ride ;-)
The ppc440 port does a fair job of keeping "board-specific" code
out of the "cpu-specific" source. The goal of course was to
provide mechanisms for each board to customize without having
to clutter the cpu-specific source with a lot of ifdefs. Most
of these mechanisms are described in the following sections.
MEMORY MANAGEMENT
=================
The ppc440 doesn't run in "real mode". The MMU must be active
at all times. Additionally, the 440 implements a 36-bit physical
memory space that gets mapped into the PowerPC 32-bit virtual
address space. So things like memory-mapped peripherals, etc must
all be mapped in. Once this is done, the 32-bit virtual address
space is then viewed as though it were physical memory.
However, this means that memory, peripherals, etc can be configured
to appear (mostly) anywhere in the virtual address space. Each board
must define its own mappings using the tlbtab (see board/ebony/init.S).
The actual TLB setup is performed by the cpu-specific code.
Although each board is free to define its own mappings, there are
several definitions to be aware of. These definitions may be used in
the cpu-specific code (vs. board-specific code), so you should
at least review these before deciding to make any changes ... it
will probably save you some headaches ;-)
CFG_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)
CFG_FLASH_BASE - The virtual address where FLASH is mapped.
CFG_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
This mapping provides access to PCI-bus memory.
CFG_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).
CFG_ISRAM_BASE - The virtual address where the 440 internal SRAM is
mapped. The internal SRAM is equivalent to 405gp OCM and is used
for the initial stack.
CFG_PCI_BASE - The virtual address where the 440 PCI-x bridge config
registers are mapped.
CFG_PCI_TARGBASE - The PCI address that is mapped to the virtual address
defined by CFG_PCI_MEMBASE.
UART / SERIAL
=================
The UART port works fine when an external serial clock is provided
(like the one on the Ebony board) and when using internal clocking.
This is controlled with the CFG_EXT_SERIAL_CLOCK flag. When using
internal clocking, the "ideal baud rate" settings in the 440GP
user manual are automatically calculated.
CONFIG_SERIAL_SOFTWARE_FIFO enables interrupt-driven serial operation.
But the last time I checked, interrupts were initialized after the
serial port causing the interrupt handler to be removed from the
handler table. This will probably be fixed soon ... or fix it
yourself and submit a patch :-)
I2C
=================
The i2c utilities have been tested on both Rev B. and Rev C. and
look good. The iprobe command implementation has been updated to
allow for 'skipped' addresses. Some i2c slaves are write only and
cause problems when a probe (read) is performed (for example the
CDCV850 clock controller at address 0x69 on the ebony board).
To prevent probing certain addresses you can define the
CFG_I2C_NOPROBES macro in your board-specific header file. When
defined, all specified addresses are skipped during a probe.
The addresses that are skipped will be displayed in the output
of the iprobe command.
For example, to prevent probing address 0x69, define the macro as
follows:
#define CFG_I2C_NOPROBES {0x69}
Similarly, to prevent probing addresses 0x69 and 0x70, define the
macro a:
#define CFG_I2C_NOPROBES {0x69, 0x70}
DDR SDRAM CONTROLLER
====================
SDRAM controller intialization using Serial Presence Detect (SPD) is
now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.
NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
processors. Traditionally, it defined a single address. For the 440 it
defines an array of addresses to support multiple banks. Address order
is significant: the addresses are used in order to program the BankN
registers. For example, two banks with i2c addresses of 0x53 (bank 0)
and 0x52 (bank 1) would be defined as follows:
#define SPD_EEPROM_ADDRESS {0x53,0x52}
PCI-X BRIDGE
====================
PCI is an area that requires lots of flexibility since every board has
its own set of constraints and configuration. This section describes the
440 implementation.
CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
is aborted and an indication is printed. This is NOT considered an
error -- only an indication that PCI shouldn't be initialized. This
gives you a chance to edit the i2c bootstrap eeproms using the i2c
utilities once you get to the U-Boot command prompt. NOTE: the default
440 bootstrap options (not using i2c eeprom) negates this bit.
The cpu-specific code sets up a default pci_controller structure
that maps in a single PCI I/O space and PCI memory space. The I/O
space begins at PCI I/O address 0 and the PCI memory space is
256 MB starting at PCI address CFG_PCI_TARGBASE. After the
pci_controller structure is initialized, the cpu-specific code will
call the routine pci_pre_init() if the CFG_PCI_PRE_INIT flag is
defined. This routine is implemented by board-specific code & is where
the board can over-ride/extend the default pci_controller structure
settings and do other pre-initialization tasks. If pci_pre_init()
returns a value of zero, PCI initialization is aborted; otherwise the
controller structure is registered and initialization continues.
The default 440GP PCI target configuration is minimal -- it assumes that
the strapping registers are set as necessary. Since the strapping bits
provide very limited flexibility, you may want to customize the boards
target configuration. If CFG_PCI_TARGET_INIT is defined, the cpu-specific
code will call the routine pci_target_init() which you must implement
in your board-specific code.
Target initialization is completed by the cpu-specific code by
initializing the subsystem id and subsystem vendor id, and then ensuring
that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.
The default PCI master initialization maps in 256 MB of pci memory
starting at PCI address CFG_PCI_MEMBASE. To customize this, define
PCI_MASTER_INIT. This will call the routine pci_master_init() in your
board-specific code rather than performing the default master
initialization.
The decision to perform PCI host configuration must often be determined
at run time. The ppc440 port differs from most other implementations in
that it requires the board to determine its host configuration at run
time rather than by using compile-time flags. This shouldn't create a
large impact on the board-specific code since the board only needs to
implement a single routine that returns a zero or non-zero value:
is_pci_host().
Justification for this becomes clear when considering systems running
in a cPCI environment:
1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
part of the PCI-to-PCI bridge). Even though the arbiter is external (the
arbiter strapping is negated), the CPU may still be required to perform
local PCI bus configuration.
2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
Depending on the configuration of the carrier boar, the PPMC board must
determine if it should configure the PCI bus at run-time. And in most
cases, access to the MONARCH# signal is board-specific (e.g. via
board-specific FPGA registers, etc).
In any event, the is_pci_host() routine gives each board the opportunity
to decide at run-time. If your board is always configured a certain way,
then just hardcode a return of 1 or 0 as appropriate.
Regards,
--Scott
<smcnutt@artesyncp.com>

53
doc/README.sbc8560
View File

@ -1,53 +0,0 @@
The port was tested on Wind River System Sbc8560 board <www.windriver.com>.
U-Boot was installed on the flash memory of the CPU card (no the SODIMM).
NOTE: Please configure uboot compile to the proper PCI frequency and
setup the appropriate DIP switch settings.
SBC8560 board:
Make sure boards switches are set to their appropriate conditions.
Refer to the Engineering Reference Guide ERG-00300-002. Of particular
importance are: 1)Tthe settings for JP4 (JP4 1-3 and 2-4), which
select the on-board FLASH device (Intel 28F128Jx); 2) The settings
for the Clock SW9 (33 MHz or 66 MHz).
Note: SW9 Settings: 66 MHz
4:1 ratio CCB clocks:SYSCLK
3:1 ration e500 Core:CCB
pos1 - on, pos2 - on, pos3 - off, pos4 - on, pos5 - off, pos6 - on
Note: SW9 Settings: 33 MHz
8:1 ratio CCB clocks:SYSCLK
3:1 ration e500 Core:CCB
pos1 - on, pos2 - on, pos3 - on, pos4 - off, pos5 - off, pos6 - on
Flashing the FLASH device with the "Wind River ICE":
1) Properly connect and configure the Wind River ICE to the
target JTAG port. This includes running the SBC8560 register script.
Make sure target memory can be read and written.
2) Build the u-boot image:
make distclean
make SBC8560_66_config or SBC8560_33_config
make CROSS_COMPILE=.../ELDK3.0/ppc_8xx-/ all
Note: reference is made to the ELDK3.0 compiler but any 85xx cross-compiler
should suffice.
3) Convert the uboot (.elf) file to a uboot.bin file (using visionClick converter).
The bin file should be converted from fffc0000 to ffffffff
4) Setup the Flash Utility (tools menu) for:
Determine the clock speed of the PCI bus and set SW9 accordingly
Note: the speed of the PCI bus defaults to the slowest PCI card
PlayBack the "default" register file for the SBC8560
Select the uboot.bin file with zero bias
Select the initialize Target prior to programming
Select the V28F640Jx (8192 x 8) 1 device FLASH Algorithm
Select the erase base address from FFFC0000 to FFFFFFFF
Select the start address from 0 with size of 4000
5) Erase and Program

53
doc/README.sched
View File

@ -1,53 +0,0 @@
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>

80
doc/README.serial_multi
View File

@ -1,80 +0,0 @@
The support for multiple serial interfaces as implemented is mainly
intended to allow for modem dial-in / dial-out while still being able
to use a serial console on a (different) serial port.
MPC8XX Specific
===============
At the moment, the ports must be split on a SMC and a SCC port on a
8xx processor; other configurations are not (yet) supported.
Support for hardware handshake has not been implemented yet (but is
in the works).
*) The default console depends on the keys pressed:
- SMC if keys not pressed (modem not enabled)
- SCC if keys pressed (modem enabled)
*) The console can be switched to SCC by any of the following commands:
setenv stdout serial_scc
setenv stdin serial_scc
setenv stderr serial_scc
*) The console can be switched to SMC by any of the following commands:
setenv stdout serial_smc
setenv stdin serial_smc
setenv stderr serial_smc
*) If a file descriptor is set to "serial" then the current serial device
will be used which, in turn, can be switched by above commands.
*) The baudrate is the same for all serial devices. But it can be switched
just after switching the console:
setenv sout serial_scc; setenv baudrate 38400
After that press 'enter' at the SCC console. Note that baudrates <38400
are not allowed on LWMON with watchdog enabled (see CFG_BAUDRATE_TABLE in
include/configs/lwmon.h).
PPC4XX Specific
===============
*) The default console is UART0
*) The console can be switched to UART1 by any of the following commands:
setenv stdout serial1
setenv stderr serial1
setenv stdin serial1
*) The console can be switched to UART0 by any of the following commands:
setenv stdout serial0
setenv stderr serial0
setenv stdin serial0
MPC5xxx Specific
================
Up to two PSCs can be used as console.
Support for hardware handshake has not been implemented yet.
*) The first (default) console port is defined by:
#define CONFIG_PSC_CONSOLE <PSC number>
*) The second (alternative) console port is defined by:
#define CONFIG_PSC_CONSOLE2 <PSC number>
*) Commands to switch to the second console:
setenv stdout serial1
setenv stderr serial1
setenv stdin serial1
*) Commands to switch to the first console:
setenv stdout serial0
setenv stderr serial0
setenv stdin serial0
*) If a file descriptor is set to "serial" then the
current serial device will be used.

20
doc/README.silent
View File

@ -1,20 +0,0 @@
The config option CONFIG_SILENT_CONSOLE can be used to quiet messages
on the console. If the option has been enabled, the output can be
silenced by setting the environment variable "silent". The variable
is latched into the global data at an early stage in the boot process
so deleting it with "setenv" will not take effect until the system is
restarted.
The following actions are taken if "silent" is set at boot time:
- Until the console devices have been initialized, output has to be
suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags".
- When the console devices have been initialized, "stdout" and
"stderr" are set to "nulldev", so subsequent messages are
suppressed automatically. Make sure to enable "nulldev" by
#defining CFG_DEVICE_NULLDEV in your board config file.
- When booting a linux kernel, the "bootargs" are fixed up so that
the argument "console=" will be in the command line, no matter how
it was set in "bootargs" before.

96
doc/README.standalone
View File

@ -1,96 +0,0 @@
Design Notes on Exporting U-Boot Functions to Standalone Applications:
======================================================================
1. The functions are exported by U-Boot via a jump table. The jump
table is allocated and initialized in the jumptable_init() routine
(common/exports.c). Other routines may also modify the jump table,
however. The jump table can be accessed as the 'jt' field of the
'global_data' structure. The slot numbers for the jump table are
defined in the <include/exports.h> header. E.g., to substitute the
malloc() and free() functions that will be available to standalone
applications, one should do the following:
DECLARE_GLOBAL_DATA_PTR;
gd->jt[XF_malloc] = my_malloc;
gd->jt[XF_free] = my_free;
Note that the pointers to the functions all have 'void *' type and
thus the compiler cannot perform type checks on these assignments.
2. The pointer to the jump table is passed to the application in a
machine-dependent way. PowerPC, ARM and MIPS architectures use a
dedicated register to hold the pointer to the 'global_data'
structure: r29 on PowerPC, r8 on ARM and k0 on MIPS. The x86
architecture does not use such a register; instead, the pointer to
the 'global_data' structure is passed as 'argv[-1]' pointer.
The application can access the 'global_data' structure in the same
way as U-Boot does:
DECLARE_GLOBAL_DATA_PTR;
printf("U-Boot relocation offset: %x\n", gd->reloc_off);
3. The application should call the app_startup() function before any
call to the exported functions. Also, implementor of the
application may want to check the version of the ABI provided by
U-Boot. To facilitate this, a get_version() function is exported
that returns the ABI version of the running U-Boot. I.e., a
typical application startup may look like this:
int my_app (int argc, char *argv[])
{
app_startup (argv);
if (get_version () != XF_VERSION)
return 1;
}
4. The default load and start addresses of the applications are as
follows:
Load address Start address
x86 0x00040000 0x00040000
PowerPC 0x00040000 0x00040004
ARM 0x0c100000 0x0c100000
MIPS 0x80200000 0x80200000
For example, the "hello world" application may be loaded and
executed on a PowerPC board with the following commands:
=> tftp 0x40000 hello_world.bin
=> go 0x40004
5. To export some additional function foobar(), the following steps
should be undertaken:
- Append the following line at the end of the include/_exports.h
file:
EXPORT_FUNC(foobar)
- Add the prototype for this function to the include/exports.h
file:
void foobar(void);
- Add the initialization of the jump table slot wherever
appropriate (most likely, to the jumptable_init() function):
gd->jt[XF_foobar] = foobar;
- Increase the XF_VERSION value by one in the include/exports.h
file
6. The code for exporting the U-Boot functions to applications is
mostly machine-independent. The only places written in assembly
language are stub functions that perform the jump through the jump
table. That said, to port this code to a new architecture, the
only thing to be provided is the code in the examples/stubs.c
file. If this architecture, however, uses some uncommon method of
passing the 'global_data' pointer (like x86 does), one should add
the respective code to the app_startup() function in that file.
Note that these functions may only use call-clobbered registers;
those registers that are used to pass the function's arguments,
the stack contents and the return address should be left intact.

59
doc/README.stxxtc
View File

@ -1,59 +0,0 @@
First, some build notes on the Silicon Turnkey eXpress XTc.
This board has both 87x/88x procesor options at various
frequencies. The configuration file has some macros for setting
the clock speed, not all have been tested. They all have
a 10MHz input clock. Please do not check in a configuration
file that selects a high speed not available on all processors.
We chose the 66MHz core and bus speed, which should be OK on
all boards. If you have a processor, lucky you! :-)
Just build a new configuration with that speed, check
the macro configuration to ensure it's correct. If the
macro is updated, please check that in, but keep default
processor speed.
The board is likely to have more than 1Mbyte of NOR boot flash.
It was also configured with a high boot vector (Dan's fault)
so the standard 8xx mapping doesn't work well. We had to move
the addresses around a little bit so one copy would work. The
flash got fragmented, and we are working on a better solution.
There is an "xtc.cfg" floating around for the BDI2000, use
that for programming a new version of U-Boot. You can probably
find it on the Silicon Turnkey eXpress (www.silicontkx.com),
Embedded Alley Solutions (embeddedalley.com), or Denx (denx.de)
servers.
The board will also have various SDRAM sizes, but the code
should automatically determine the amount of memory.
There are a couple of different board versions, visually
they use different BGA or surface mount memory parts. However,
they are logically the same board.
Now, some operational notes.
The board has the option of sporting two FEC Ethernet ports.
The second port isn't configured to be automatically available
because it would cause U-Boot to generate a board data structure
(the bd_t) with multiple MAC addresses and be incompatible with
standard 8xx kernel builds. You can use/test the second FEC
in U-Boot by assigning an 'eth1addr' and selecting the second
FEC as the port to use.
Since this is just a development board and not a product, STx
does not assign unique MAC addresses. We just pilfer the
"default" ones used by Wolfgang on some other boards. Please
ensure you assign unique MAC addresses when using these boards.
The serial port baud rate is 38400, because that's the way
I like it :-)
Thanks to Pantelis for lots of the work on this board port.
Have Fun!
-- Dan
15 August 2005

80
doc/README.usb
View File

@ -1,80 +0,0 @@
/*
* (C) Copyright 2001
* Denis Peter, MPL AG Switzerland
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*
*/
USB Support for PIP405 and MIP405 (UHCI)
========================================
The USB support is implemented on the base of the UHCI Host
controller.
Currently supported are USB Hubs, USB Keyboards and USB Floppys.
Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
How it works:
-------------
The USB (at least the USB UHCI) needs a frame list (4k), transfer
descripor and queue headers which are all located in the main memory.
The UHCI allocates every milisecond the PCI bus and reads the current
frame pointer. This may cause to crash the OS during boot. So the USB
_MUST_ be stopped during OS boot. This is the reason, why the USB is
NOT automatically started during start-up. If someone needs the USB
he has to start it and should therefore be aware that he had to stop
it before booting the OS.
For USB keyboards this can be done by a script which is automatically
started after the U-Boot is up and running. To boot an OS with a an
USB keyboard another script is necessary, which first disables the
USB and then executes the boot command. If the boot command fails,
the script can reenable the USB kbd.
Common USB Commands:
- usb start:
- usb reset: (re)starts the USB. All USB devices will be
initialized and a device tree is build for them.
- usb tree: shows all USB devices in a tree like display
- usb info [dev]: shows all USB infos of the device dev, or of all
the devices
- usb stop [f]: stops the USB. If f==1 the USB will also stop if
an USB keyboard is assigned as stdin. The stdin
is then switched to serial input.
Storage USB Commands:
- usb scan: scans the USB for storage devices.The USB must be
running for this command (usb start)
- usb device [dev]: show or set current USB staorage device
- usb part [dev]: print partition table of one or all USB storage
devices
- usb read addr blk# cnt:
read `cnt' blocks starting at block `blk#'to
memory address `addr'
- usbboot addr dev:part:
boot from USB device
Config Switches:
----------------
CFG_CMD_USB enables basic USB support and the usb command
CONFIG_USB_UHCI defines the lowlevel part.A lowlevel part must be defined if
using CFG_CMD_USB
CONFIG_USB_KEYBOARD enables the USB Keyboard
CONFIG_USB_STORAGE enables the USB storage devices

30
doc/README.video
View File

@ -1,30 +0,0 @@
/*
* (C) Copyright 2000
* Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
U-Boot MPC8xx video controller driver
======================================
The driver has been tested with the following configurations:
- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
- GENIETV with AD7177 on a PAL TV (YCbYCr) - arsenio@tin.it

82
doc/README.xpedite1k
View File

@ -1,82 +0,0 @@
XES XPedite1000 Board
Last Update: December 29, 2003
=======================================================================
This file contains some handy info regarding U-Boot and the XES
XPedite1000 PPC440GX PrPMC board. See the README.ppc440 for additional
information.
SWITCH SETTINGS & JUMPERS
==========================
Jumpers selected for AMD29LV040B flash part as the boot flash.
I2C Strap EEPROM & Environment Settings
=======================================
The XPedite1000 uses a single I2C eeprom for the 440 strappings and for
the environment variables. The first page (256 bytes) contains the
strappings and the 2 EMAC HW Ethernet addresses. Be careful not to
change the 1st page of the EEPROM! Unpopulated jumper J560 can get you
out of trouble as it disables the strapping read from EEPROM.
I2C iprobe
=====================
The i2c utilities work and have been tested on Rev B. of the 440GX. See
README.ebony for more information about i2c probing with the 440.
GETTING OUT OF I2C TROUBLE
===========================
(Direct quote from README.ebony)
If you're like me ... you may have screwed up your bootstrap serial
eeprom ... or worse, your SPD eeprom when experimenting with the
i2c commands. If so, here are some ideas on how to get out of
trouble:
Serial bootstrap eeprom corruption:
-----------------------------------
Power down the board and set the following straps:
J560 - closed
This will select the default sys0 and sys1 settings (the serial
eeproms are not used). Then power up the board and fix the serial
eeprom using the imm command. Here are the values I currently
use:
=> imd 50 0 10
0000: 85 7d 42 06 07 80 11 00 00 00 00 00 00 00 00 00 .}B.............
Once you have the eeproms set correctly change the
J560 straps as you desire.
PPC440GX Ethernet EMACs
=======================
The XES XPedite1000 uses emac 2 & 3 and ignores emac 0 & 1. PHYs are connected
only to emac 2 & 3. The HW Ethernet addresses are read from the i2c eeprom and
placed in the bd info structure for enet2addr and enet3addr. The ethernet driver
senses that enetaddr and enet1addr are 0's and does not use them.
As of this writing gigabit ethernet and the TCPIP acceleration hardware is not
supported.
Flash Support
=============
As of this writing, there is support for the 1/2mb boot flash only. User flash
is not yet supported.
Regards,
--Travis
<travis.sawyer@sandburst.com>

29
doc/TODO-i386
View File

@ -1,29 +0,0 @@
i386 port missing features:
* i386 cleaness (wbinvld is 486+ ... )
* Pentium TSC timer/udelay
* setup the BIOS data area and BIOS equipment word to reflect machine config.
* Make reset work (from Linux and from the boot prompt)
* DMA, FDC, RTC, KBC initialization
* split of part of cpu/i386/interrupt.c to cpu/i385/entry.c?
* re-entry of protected mode from real mode, should be added to realmode_switch.S
(and used by INT 10h and INT 16h handlers for console I/O during early
linux boot...)
* missing functions in lib_i386 and cpu/i386
* speaker beep interface
SC520 missing features:
* Watchdog
* SC520 timer/udelay
* SC520 3rd PIC
* SC520 ICE serial
* SC520 MMCR reset
SC520 CDP board support missing features:
* environment in sram
SC520 CDP board support bugs:
* SPI EEPROM support does not work
* 0x680 LEDS dos not work for me
* is it possible to make both the internal serial ports and the
ports on the sio work at the same time?