mptcp/openmptcprouter
1
0
Fork 0
mirror of https://github.com/Ysurac/openmptcprouter.git synced 2025-03-09 15:40:20 +00:00
Code Issues Releases Wiki Activity

Kernel 5.4 RUTX support

Browse source
This commit is contained in:
Ycarus (Yannick Chabanois) 2023-08-14 17:47:02 +02:00
parent 839fcf1cab
commit cfce9f52b2
7376 changed files with 3902 additions and 546 deletions
Download patch file Download diff file Expand all files Collapse all files

46
common/package/boot/uboot-ipq40xx/src/doc/I2C_Edge_Conditions Normal file
View file

@ -0,0 +1,46 @@
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 CONFIG_SYS_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)

110
common/package/boot/uboot-ipq40xx/src/doc/README-integrator Normal file
View file

@ -0,0 +1,110 @@
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
arch/arm/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
common/package/boot/uboot-ipq40xx/src/doc/README.440-DDR-performance Normal file
View file

@ -0,0 +1,90 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.AMCC-eval-boards-cleanup Normal file
View file

@ -0,0 +1,31 @@
---------------------------------------------------------------------
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
common/package/boot/uboot-ipq40xx/src/doc/README.ARM-SoC Normal file
View file

@ -0,0 +1,31 @@
[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 arch/arm/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
$(CPUDIR)/
and code that is specific to some SoC (i.e. vendor specific
peripherals around the core) is moved into
$(CPUDIR)/$(SOC)/
Thus a library/archive "$(CPUDIR)/$(SOC)/lib$(SOC).a" will be build
and linked. Examples will be
arch/arm/cpu/arm920t/imx/
arch/arm/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
common/package/boot/uboot-ipq40xx/src/doc/README.ARM-memory-map Normal file
View file

@ -0,0 +1,17 @@
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 CONFIG_SYS_TEXT_BASE (0xA07E0000); it seems
CONFIG_SYS_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.

25
common/package/boot/uboot-ipq40xx/src/doc/README.AVR32 Normal file
View file

@ -0,0 +1,25 @@
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, along with non-GNU programming
and debugging support, can be downloaded from
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
A full set of u-boot, kernel and filesystem images can be built using
buildroot. This will also produce a working toolchain which can be
used instead of the official GNU toolchain above. A customized version
of buildroot for AVR32 can be downloaded here:
http://www.atmel.no/buildroot/
The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and
other associated software are actively supported by Atmel Corporation.

208
common/package/boot/uboot-ipq40xx/src/doc/README.AVR32-port-muxing Normal file
View file

@ -0,0 +1,208 @@
AVR32 Port multiplexer configuration
====================================
On AVR32 chips, most external I/O pins are routed through a port
multiplexer. There are currently two kinds of port multiplexer
hardware around with different register interfaces:
* PIO (AT32AP700x; this is also used on ARM AT91 chips)
* GPIO (all other AVR32 chips)
The "PIO" variant supports multiplexing up to two peripherals per pin
in addition to GPIO (software control). Each pin has configurable
pull-up, glitch filter, interrupt and multi-drive capabilities.
The "GPIO" variant supports multiplexing up to four peripherals per
pin in addition to GPIO. Each pin has configurable
pull-up/pull-down/buskeeper, glitch filter, interrupt, open-drain and
schmitt-trigger capabilities, as well as configurable drive strength
and slew rate control.
Both controllers are configured using the same API, but the functions
may accept different values for some parameters depending on the
actual portmux implementation, and some parameters may be ignored by
one of the implementation (e.g. the "PIO" implementation will ignore
the drive strength flags since the hardware doesn't support
configurable drive strength.)
Selecting the portmux implementation
------------------------------------
Since u-boot is lacking a Kconfig-style configuration engine, the
portmux implementation must be selected manually by defining one of
the following symbols:
CONFIG_PORTMUX_PIO
CONFIG_PORTMUX_GPIO
depending on which implementation the chip in question uses.
Identifying pins
----------------
The portmux configuration functions described below identify the pins
to act on based on two parameters: A "port" (i.e. a block of pins
that somehow belong together) and a pin mask. Both are defined in an
implementation-specific manner.
The available ports are defined on the form
#define PORTMUX_PORT_A (something)
where "A" matches the identifier given in the chip's data sheet, and
"something" is whatever the portmux implementation needs to identify
the port (usually a memory address).
The pin mask is a bitmask where each '1' bit indicates a pin to apply
the current operation to. The width of the bitmask may vary from port
to port, but it is never wider than 32 bits (which is the width of
'unsigned long' on avr32).
Selecting functions
-------------------
Each pin can either be assigned to one of a predefined set of on-chip
peripherals, or it can be set up to be controlled by software. For the
former case, the portmux implementation defines an enum containing all
the possible peripheral functions that can be selected. For example,
the PIO implementation, which allows multiplexing two peripherals per
pin, defines it like this:
enum portmux_function {
PORTMUX_FUNC_A,
PORTMUX_FUNC_B,
};
To configure a set of pins to be connected to a given peripheral
function, the following function is used.
void portmux_select_peripheral(void *port, unsigned long pin_mask,
enum portmux_function func, unsigned long flags);
To configure a set of pins to be controlled by software (GPIO), the
following function is used. In this case, no "function" argument is
required since "GPIO" is a function in its own right.
void portmux_select_gpio(void *port, unsigned int pin_mask,
unsigned long flags);
Both of these functions take a "flags" parameter which may be used to
alter the default configuration of the pin. This is a bitmask of
various flags defined in an implementation-specific way, but the names
of the flags are the same on all implementations.
PORTMUX_DIR_OUTPUT
PORTMUX_DIR_INPUT
These mutually-exclusive flags configure the initial direction of the
pins. PORTMUX_DIR_OUTPUT means that the pins are driven by the CPU,
while PORTMUX_DIR_INPUT means that the pins are tristated by the CPU.
These flags are ignored by portmux_select_peripheral().
PORTMUX_INIT_HIGH
PORTMUX_INIT_LOW
These mutually-exclusive flags configure the initial state of the
pins: High (Vdd) or low (Vss). They are only effective when
portmux_select_gpio() is called with the PORTMUX_DIR_OUTPUT flag set.
PORTMUX_PULL_UP
PORTMUX_PULL_DOWN
PORTMUX_BUSKEEPER
These mutually-exclusive flags are used to enable any on-chip CMOS
resistors connected to the pins. PORTMUX_PULL_UP causes the pins to be
pulled up to Vdd, PORTMUX_PULL_DOWN causes the pins to be pulled down
to Vss, and PORTMUX_BUSKEEPER will keep the pins in whatever state
they were left in by whatever was driving them last. If none of the
flags are specified, the pins are left floating if no one are driving
them; this is only recommended for always-output pins (e.g. extern
address and control lines driven by the CPU.)
Note that the "PIO" implementation will silently ignore the
PORTMUX_PULL_DOWN flag and interpret PORTMUX_BUSKEEPER as
PORTMUX_PULL_UP.
PORTMUX_DRIVE_MIN
PORTMUX_DRIVE_LOW
PORTMUX_DRIVE_HIGH
PORTMUX_DRIVE_MAX
These mutually-exclusive flags determine the drive strength of the
pins. PORTMUX_DRIVE_MIN will give low power-consumption, but may cause
corruption of high-speed signals. PORTMUX_DRIVE_MAX will give high
power-consumption, but may be necessary on pins toggling at very high
speeds. PORTMUX_DRIVE_LOW and PORTMUX_DRIVE_HIGH specify something in
between the other two.
Note that setting the drive strength too high may cause excessive
overshoot and EMI problems, which may in turn cause signal corruption.
Also note that the "PIO" implementation will silently ignore these
flags.
PORTMUX_OPEN_DRAIN
This flag will configure the pins as "open drain", i.e. setting the
pin state to 0 will drive it low, while setting it to 1 will leave it
floating (or, in most cases, let it be pulled high by an internal or
external pull-up resistor.) In the data sheet for chips using the
"PIO" variant, this mode is called "multi-driver".
Enabling specific peripherals
-----------------------------
In addition to the above functions, each chip provides a set of
functions for setting up the port multiplexer to use a given
peripheral. The following are some of the functions available.
All the functions below take a "drive_strength" parameter, which must
be one of the PORTMUX_DRIVE_x flags specified above. Any other
portmux flags will be silently filtered out.
To set up the External Bus Interface (EBI), call
void portmux_enable_ebi(unsigned int bus_width,
unsigned long flags, unsigned long drive_strength)
where "bus_width" must be either 16 or 32. "flags" can be any
combination of the following flags.
PORTMUX_EBI_CS(x) /* Enable chip select x */
PORTMUX_EBI_NAND /* Enable NAND flash interface */
PORTMUX_EBI_CF(x) /* Enable CompactFlash interface x */
PORTMUX_EBI_NWAIT /* Enable NWAIT signal */
To set up a USART, call
void portmux_enable_usartX(unsigned long drive_strength);
where X is replaced by the USART instance to be configured.
To set up an ethernet MAC:
void portmux_enable_macbX(unsigned long flags,
unsigned long drive_strength);
where X is replaced by the MACB instance to be configured. "flags" can
be any combination of the following flags.
PORTMUX_MACB_RMII /* Just set up the RMII interface */
PORTMUX_MACB_MII /* Set up full MII interface */
PORTMUX_MACB_SPEED /* Enable the SPEED pin */
To set up the MMC controller:
void portmux_enable_mmci(unsigned long slot, unsigned long flags
unsigned long drive_strength);
where "slot" identifies which of the alternative SD card slots to
enable. "flags" can be any combination of the following flags:
PORTMUX_MMCI_4BIT /* Enable 4-bit SD card interface */
PORTMUX_MMCI_8BIT /* Enable 8-bit MMC+ interface */
PORTMUX_MMCI_EXT_PULLUP /* Board has external pull-ups */
To set up a SPI controller:
void portmux_enable_spiX(unsigned long cs_mask,
unsigned long drive_strength);
where X is replaced by the SPI instance to be configured. "cs_mask" is
a 4-bit bitmask specifying which of the four standard chip select
lines to set up as GPIOs.

156
common/package/boot/uboot-ipq40xx/src/doc/README.COBRA5272 Normal file
View file

@ -0,0 +1,156 @@
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 CONFIG_SYS_TEXT_BASE should be
CONFIG_SYS_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 CONFIG_SYS_TEXT_BASE should be
CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.EVB-64260-750CX Normal file
View file

@ -0,0 +1,7 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.INCA-IP Normal file
View file

@ -0,0 +1,57 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.IPHASE4539 Normal file
View file

@ -0,0 +1,358 @@
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
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
source - run script from memory
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/powerpc/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
common/package/boot/uboot-ipq40xx/src/doc/README.IceCube Normal file
View file

@ -0,0 +1,13 @@
---------------------------------------------------------------------------
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
common/package/boot/uboot-ipq40xx/src/doc/README.JFFS2 Normal file
View file

@ -0,0 +1,74 @@
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 CONFIG_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 CONFIG_SYS_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.
CONFIG_SYS_JFFS2_FIRST_BANK
defined the first flash bank to use
CONFIG_SYS_JFFS2_FIRST_SECTOR
defines the first sector to use
The second way is to define CONFIG_SYS_JFFS_CUSTOM_PART and implement the
jffs2_part_info(int part_num) function in your board specific files.
In this mode CONFIG_SYS_JFFS2_FIRST_BANK and CONFIG_SYS_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 CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.JFFS2_NAND Normal file
View file

@ -0,0 +1,24 @@
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 partition 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
CONFIG_SYS_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.

78
common/package/boot/uboot-ipq40xx/src/doc/README.LED Normal file
View file

@ -0,0 +1,78 @@
Status LED
========================================
This README describes the status LED API.
The API is defined by the include file include/status_led.h
The first step is to define CONFIG_STATUS_LED in the board config file.
If the LED support is only for a single board, define CONFIG_BOARD_SPECIFIC_LED
in the board config file.
At a minimum, these macros must be defined at
STATUS_LED_BIT
STATUS_LED_STATE
STATUS_LED_PERIOD
If there are multiple status LED's define
STATUS_LED_BIT<n>
STATUS_LED_STATE<n>
STATUS_LED_PERIOD<n>
Where <n> can a integer 1 through 3.
STATUS_LED_BIT is passed into the __led_* functions to identify which LED is
being acted on. As such, the value choose must be unique with with respect to
the other STATUS_LED_BIT's. Mapping the value to a physical LED is the
reponsiblity of the __led_* function.
STATUS_LED_STATE is the initial state of the LED. It should be set to one of
these values: STATUS_LED_OFF or STATUS_LED_ON.
STATUS_LED_PERIOD is how long is the LED blink period. This usually set to
(CONFIG_SYS_HZ / <N>) where <N> is the frequency of the blink. Typical values
range from 2 to 10.
Some other LED macros
STATUS_LED_BOOT is the LED to light when the board is booting. This must be a
valid STATUS_LED_BIT value.
STATUS_LED_RED is the red LED. It is used signal errors. This must be a valid
STATUS_LED_BIT value. Other similar color LED's are STATUS_LED_YELLOW and
STATUS_LED_BLUE.
These board must define these functions
__led_init is called once to initialize the LED to STATUS_LED_STATE. One time
start up code should be placed here.
__led_set is called to change the state of the LED.
__led_toggle is called to toggle the current state of the LED.
Colour LED
========================================
Colour LED's are at present only used by ARM.
The functions names explain their purpose.
coloured_LED_init
red_LED_on
red_LED_off
green_LED_on
green_LED_off
yellow_LED_on
yellow_LED_off
blue_LED_on
blue_LED_off
These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define
these functions in the board specific source.
TBD : Describe older board dependent macros similar to what is done for
CONFIG_TQM8xxL.
TBD : Describe general support via asm/status_led.h

26
common/package/boot/uboot-ipq40xx/src/doc/README.LED_display Normal file
View file

@ -0,0 +1,26 @@
LED display internal API
=======================================
This README describes the LED display API.
The API is defined by the include file include/led-display.h
The first step in to define CONFIG_CMD_DISPLAY in the board config file.
Then you need to provide the following functions to access LED display:
void display_set(int cmd);
This function should control the state of the LED display. Argument is
an ORed combination of the following values:
DISPLAY_CLEAR -- clear the display
DISPLAY_HOME -- set the position to the beginning of display
int display_putc(char c);
This function should display it's parameter on the LED display in the
current position. Returns the displayed character on success or -1 in
case of failure.
With this functions defined 'display' command will display it's
arguments on the LED display (or clear the display if called without
arguments).

22
common/package/boot/uboot-ipq40xx/src/doc/README.Lite5200B_low_power Normal file
View file

@ -0,0 +1,22 @@
Lite5200B wakeup from low-power mode (CONFIG_LITE5200B_PM)
----------------------------------------------------------
Low-power mode as described in Lite5200B User's Manual, means that
with support of MC68HLC908QT1 microcontroller (refered to as QT),
everything but the SDRAM can be powered down. This brings
maximum power saving, while one can still restore previous state
quickly.
Quick overview where U-Boot comes into the picture:
- OS saves device states
- OS saves wakeup handler address to physical 0x0, puts SDRAM into
self-refresh and signals to QT, it should power down the board
- / board is sleeping here /
- someone presses SW4 (connected to QT)
- U-Boot checks PSC2_4 pin, if QT drives it down, then we woke up,
so get SDRAM out of self-refresh and transfer control to OS
wakeup handler
- OS restores device states
This was tested on Linux with USB and Ethernet in use. Adding
support for other devices is an OS issue.

68
common/package/boot/uboot-ipq40xx/src/doc/README.MBX Normal file
View file

@ -0,0 +1,68 @@
IMPORTANT NOTE - read before defining CONFIG_SYS_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 CONFIG_SYS_USE_OSCCLK if your
MBX8xx board is using the OSCM clocking mode.
You better know what you are doing here.

24
common/package/boot/uboot-ipq40xx/src/doc/README.MPC866 Normal file
View file

@ -0,0 +1,24 @@
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
CONFIG_SYS_8xx_CPUCLK_MIN - minimum allowed CPU clock
CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.Modem Normal file
View file

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

55
common/package/boot/uboot-ipq40xx/src/doc/README.N1213 Normal file
View file

@ -0,0 +1,55 @@
N1213 is a configurable hard/soft core of NDS32's N12 CPU family.
Features
========
CPU Core
- 16-/32-bit mixable instruction format.
- 32 general-purpose 32-bit registers.
- 8-stage pipeline.
- Dynamic branch prediction.
- 32/64/128/256 BTB.
- Return address stack (RAS).
- Vector interrupts for internal/external.
interrupt controller with 6 hardware interrupt signals.
- 3 HW-level nested interruptions.
- User and super-user mode support.
- Memory-mapped I/O.
- Address space up to 4GB.
Memory Management Unit
- TLB
- 4/8-entry fully associative iTLB/dTLB.
- 32/64/128-entry 4-way set-associati.ve main TLB.
- TLB locking support
- Optional hardware page table walker.
- Two groups of page size support.
- 4KB & 1MB.
- 8KB & 1MB.
Memory Subsystem
- I & D cache.
- Virtually indexed and physically tagged.
- Cache size: 8KB/16KB/32KB/64KB.
- Cache line size: 16B/32B.
- Set associativity: 2-way, 4-way or direct-mapped.
- Cache locking support.
- I & D local memory (LM).
- Size: 4KB to 1MB.
- Bank numbers: 1 or 2.
- Optional 1D/2D DMA engine.
- Internal or external to CPU core.
Bus Interface
- Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports.
- Synchronous High speed memory port.
(HSMP): 0, 1 or 2 ports.
Debug
- JTAG debug interface.
- Embedded debug module (EDM).
- Optional embedded program tracer interface.
Miscellaneous
- Programmable data endian control.
- Performance monitoring mechanism.

41
common/package/boot/uboot-ipq40xx/src/doc/README.NDS32 Normal file
View file

@ -0,0 +1,41 @@
NDS32 is a new high-performance 32-bit RISC microprocessor core.
http://www.andestech.com/
AndeStar ISA
============
AndeStar is a patent-pending 16-bit/32-bit mixed-length instruction set to
achieve optimal system performance, code density, and power efficiency.
It contains the following features:
- Intermixable 32-bit and 16-bit instruction sets without the need for
mode switch.
- 16-bit instructions as a frequently used subset of 32-bit instructions.
- RISC-style register-based instruction set.
- 32 32-bit General Purpose Registers (GPR).
- Upto 1024 User Special Registers (USR) for existing and extension
instructions.
- Rich load/store instructions for...
- Single memory access with base address update.
- Multiple aligned and unaligned memory accesses for memory copy and stack
operations.
- Data prefetch to improve data cache performance.
- Non-bus locking synchronization instructions.
- PC relative jump and PC read instructions for efficient position independent
code.
- Multiply-add and multiple-sub with 64-bit accumulator.
- Instruction for efficient power management.
- Bi-endian support.
- Three instruction extension space for application acceleration:
- Performance extension.
- Andes future extensions (for floating-point, multimedia, etc.)
- Customer extensions.
AndesCore CPU
=============
Andes Technology has 4 families of CPU cores: N12, N10, N9, N8.
For details about N12 CPU family, please check doc/README.N1213.
The NDS32 ports of u-boot, the Linux kernel, the GNU toolchain and
other associated software are actively supported by Andes Technology Corporation.

92
common/package/boot/uboot-ipq40xx/src/doc/README.NetConsole Normal file
View file

@ -0,0 +1,92 @@
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:
tools/netconsole <ip> [port]
The script uses netcat to talk to the board over UDP. It requires you to
specify the target IP address (or host name, assuming DNS is working). The
script can be interrupted by pressing ^T (CTRL-T).
Be aware that in some distributives (Fedora Core 5 at least)
usage of nc has been changed and -l and -p options are considered
as mutually exclusive. If nc complains about options provided,
you can just remove the -p option from the script.
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. It will be built when compiling for a board which
has CONFIG_NETCONSOLE defined. If the netconsole script can find it
in PATH or in the same directory, it will be used instead.
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
common/package/boot/uboot-ipq40xx/src/doc/README.OFT Normal file
View file

@ -0,0 +1,28 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.OXC Normal file
View file

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

375
common/package/boot/uboot-ipq40xx/src/doc/README.PIP405 Normal file
View file

@ -0,0 +1,375 @@
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
- arch/powerpc/cpu/ppc4xx/405gp_pci.c excluded file from PIP405
- arch/powerpc/cpu/ppc4xx/i2c.c added 16bit read write I2C support
added page write
- arch/powerpc/cpu/ppc4xx/speed.c added get_PCI_freq
- arch/powerpc/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 CONFIG_CMD_FDC and CONFIG_CMD_SCSI
- include/config_hymod.h excluded CONFIG_CMD_FDC and CONFIG_CMD_SCSI
- 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:
-------------
CONFIG_CMD_SCSI SCSI Support
CONFIG_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
CONFIG_SYS_SCSI_MAX_LUN 8 number of supported LUNs
CONFIG_SYS_SCSI_MAX_SCSI_ID 7 maximum SCSI ID (0..6)
CONFIG_SYS_SCSI_MAX_DEVICE CONFIG_SYS_SCSI_MAX_SCSI_ID * CONFIG_SYS_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:
---------------------------------
CONFIG_SYS_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
Environment / Console:
----------------------
CONFIG_SYS_CONSOLE_IS_IN_ENV if defined, stdin, stdout and stderr used from
the values stored in the evironment.
CONFIG_SYS_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.
CONFIG_SYS_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 CONFIG_SYS_ISA_IO_BASE_ADDRESS
+ 0x3F0. Enabled with define CONFIG_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 CONFIG_SYS_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
CONFIG_SYS_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 CONFIG_SYS_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:
- arch/powerpc/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 arch/powerpc/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:
- arch/powerpc/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 CONFIG_SYS_EEPROM_PAGE_WRITE_ENABLE.
Changed files:
- arch/powerpc/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
CONFIG_SYS_CONSOLE_IS_IN_ENV is defined.
If CONFIG_SYS_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 CONFIG_SYS_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.

743
common/package/boot/uboot-ipq40xx/src/doc/README.POST Normal file
View file

@ -0,0 +1,743 @@
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 a board defines
CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined
the test will pass if any I2C device is found.
The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C
devices which may or may not be present when using
CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not.
This is useful in cases when I2C devices are optional (eg on a
daughtercard that may or may not be present) or not critical
to board operation.
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
arch/powerpc/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
arch/powerpc/cpu/mpc8xx/serial.c.
2.2.3.3. USB test
TBD
2.2.3.4. SPI test
TBD

163
common/package/boot/uboot-ipq40xx/src/doc/README.PlanetCore Normal file
View file

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

19
common/package/boot/uboot-ipq40xx/src/doc/README.RPXClassic Normal file
View file

@ -0,0 +1,19 @@
# 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
common/package/boot/uboot-ipq40xx/src/doc/README.RPXlite Normal file
View file

@ -0,0 +1,877 @@
# 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 */
arch/powerpc/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
common/package/boot/uboot-ipq40xx/src/doc/README.SBC8560 Normal file
View file

@ -0,0 +1,57 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.SNTP Normal file
View file

@ -0,0 +1,17 @@
To use SNTP support, add define CONFIG_CMD_SNTP to 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
environment 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.

68
common/package/boot/uboot-ipq40xx/src/doc/README.SPL Normal file
View file

@ -0,0 +1,68 @@
Generic SPL framework
=====================
Overview
--------
To unify all existing implementations for a secondary program loader (SPL)
and to allow simply adding of new implementations this generic SPL framework
has been created. With this framework almost all source files for a board
can be reused. No code duplication or symlinking is necessary anymore.
How it works
------------
There is a new directory TOPDIR/spl which contains only a Makefile.
The object files are built separately for SPL and placed in this directory.
The final binaries which are generated are u-boot-spl, u-boot-spl.bin and
u-boot-spl.map.
During the SPL build a variable named CONFIG_SPL_BUILD is exported
in the make environment and also appended to CPPFLAGS with -DCONFIG_SPL_BUILD.
Source files can therefore be compiled for SPL with different settings.
ARM-based boards have previously used the option CONFIG_PRELOADER for it.
For example:
ifeq ($(CONFIG_SPL_BUILD),y)
COBJS-y += board_spl.o
else
COBJS-y += board.o
endif
COBJS-$(CONFIG_SPL_BUILD) += foo.o
#ifdef CONFIG_SPL_BUILD
foo();
#endif
The building of SPL images can be with:
#define CONFIG_SPL
Because SPL images normally have a different text base, one has to be
configured by defining CONFIG_SPL_TEXT_BASE. The linker script has to be
defined with CONFIG_SPL_LDSCRIPT.
To support generic U-Boot libraries and drivers in the SPL binary one can
optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options
are supported:
CONFIG_SPL_LIBCOMMON_SUPPORT (common/libcommon.o)
CONFIG_SPL_LIBDISK_SUPPORT (disk/libdisk.o)
CONFIG_SPL_I2C_SUPPORT (drivers/i2c/libi2c.o)
CONFIG_SPL_GPIO_SUPPORT (drivers/gpio/libgpio.o)
CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o)
CONFIG_SPL_SERIAL_SUPPORT (drivers/serial/libserial.o)
CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o)
CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o)
CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o)
CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o)
CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o)
CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
CONFIG_SPL_DMA_SUPPORT (drivers/dma/libdma.o)
CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o)
CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)

394
common/package/boot/uboot-ipq40xx/src/doc/README.Sandpoint8240 Normal file
View file

@ -0,0 +1,394 @@
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 Environment 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 Environment 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 Environment 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
common/package/boot/uboot-ipq40xx/src/doc/README.TQM8260 Normal file
View file

@ -0,0 +1,415 @@
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
arch/powerpc/cpu/mpc8260/Makefile - soft_i2c.o module added
arch/powerpc/cpu/mpc8260/ether_scc.c - TQM8260-specific definitions added, an obvious
bug fixed (fcr -> scr)
arch/powerpc/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
arch/powerpc/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
CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.VLAN Normal file
View file

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

74
common/package/boot/uboot-ipq40xx/src/doc/README.ag101 Normal file
View file

@ -0,0 +1,74 @@
Andes Technology SoC AG101
==========================
AG101 is the first SoC produced by Andes Technology using N1213 CPU core.
AG101 has integrated both AHB and APB bus and many periphals for application
and product development.
ADP-AG101
=========
ADP-AG101 is the SoC with AG101 hardcore CPU.
Please check http://www.andestech.com/p2-4.htm for detail of this SoC.
Configurations
==============
CONFIG_MEM_REMAP:
Doing memory remap is essential for preparing some non-OS or RTOS
applications.
This is also a must on ADP-AG101 board.
(While other boards may not have this problem).
The reason is because the ROM/FLASH circuit on PCB board.
AG101-A0 board has 2 jumpers MA17 and SW5 to configure which
ROM/FLASH is used to boot.
When SW5 = "0101", MA17 = LO, the ROM is connected to BANK0,
and the FLASH is connected to BANK1.
When SW5 = "1010", MA17 = HI, the ROM is disabled (still at BANK0),
and the FLASH is connected to BANK0.
It will occur problem when doing flash probing if the flash is at
BANK0 (0x00000000) while memory remapping was skipped.
Other board like ADP-AG101P may not enable this since there is only
a FLASH connected to bank0.
CONFIG_SKIP_LOWLEVEL_INIT:
If you want to boot this system from FLASH and bypass e-bios (the
other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT
in "include/configs/adp-ag101.h".
Build and boot steps
====================
build:
1. Prepare the toolchains and make sure the $PATH to toolchains is correct.
2. Use `make adp-ag101` in u-boot root to build the image.
burn u-boot to flash:
1. Make sure the MA17 (J16) is Lo.
2. Make sure the dip switch SW5 is set to "0101".
3. Power On. Press button "S1", then press button "SW1", then you will found the
debug LED show 67 means the system successfully booted into e-bios.
Now you can control the e-bios boot loader from your console.
4. Under "Command>>" prompt, enter "97" (CopyImageFromCard)
5. Under "Type Dir Name of [CF/SD] =>" promtp, enter "c".
6. Under "Enter Filename =>" prompt, enter the file name of u-boot image you
just build. It is usually "u-boot.bin".
7. Under "Enter Dest. Address =>" prompt, enter the memory address where you
want to put the binary from SD card to RAM.
Address "0x500000" is our suggestion.
8. Under "Command>>" prompt again, enter "55" (CLI) to use interactive command
environment.
9. Under "CLI>" prompt, enter "burn 0x500000 0x80400000 0x30000" to burn the
binary from RAM to FLASH.
10. Under "CLI>" prompt, enter "exit" to finish the burn process.
boot u-boot from flash:
1. Make sure the MA17 (J16) is Hi).
2. Make sure the dip switch SW5 is set to "1010".
3. Power On. Press button "S1", then you will see the debug LED count to 20.
4. Now you can use u-boot on ADP-AG101 board.

36
common/package/boot/uboot-ipq40xx/src/doc/README.ag102 Normal file
View file

@ -0,0 +1,36 @@
Andes Technology SoC AG102
==========================
AG102 is the second SoC produced by Andes Technology using N1213 CPU core
with FPU and DDR contoller support.
AG102 has integrated both AHB and APB bus and many periphals for application
and product development.
ADP-AG102
=========
ADP-AG102 is the SoC with AG102 hardcore CPU.
Configurations
==============
CONFIG_MEM_REMAP:
Doing memory remap is essential for preparing some non-OS or RTOS
applications.
CONFIG_SKIP_LOWLEVEL_INIT:
If you want to boot this system from SPI ROM and bypass e-bios (the
other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT
in "include/configs/adp-ag102.h".
Build and boot steps
====================
build:
1. Prepare the toolchains and make sure the $PATH to toolchains is correct.
2. Use `make adp-ag102` in u-boot root to build the image.
Burn u-boot to SPI ROM:
====================
This section will be added later.

482
common/package/boot/uboot-ipq40xx/src/doc/README.alaska8220 Normal file
View file

@ -0,0 +1,482 @@
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
- arch/powerpc/lib/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
- arch/powerpc/cpu/mpc8220/dma.h multi-channel dma header file
- arch/powerpc/cpu/mpc8220/dramSetup.h dram setup header file
- arch/powerpc/cpu/mpc8220/fec.h MPC8220 FEC header file
- arch/powerpc/cpu/mpc8220/cpu.c cpu specific code
- arch/powerpc/cpu/mpc8220/cpu_init.c Flexbus ChipSelect and Mux pins setup
- arch/powerpc/cpu/mpc8220/dramSetup.c MPC8220 DDR SDRAM setup
- arch/powerpc/cpu/mpc8220/fec.c MPC8220 FEC driver
- arch/powerpc/cpu/mpc8220/i2c.c MPC8220 I2C driver
- arch/powerpc/cpu/mpc8220/interrupts.c interrupt support (not enable)
- arch/powerpc/cpu/mpc8220/loadtask.c load dma
- arch/powerpc/cpu/mpc8220/speed.c system, pci, flexbus, pev, and cpu clock
- arch/powerpc/cpu/mpc8220/traps.c exception
- arch/powerpc/cpu/mpc8220/uart.c MPC8220 UART driver
- arch/powerpc/cpu/mpc8220/Makefile Makefile
- arch/powerpc/cpu/mpc8220/config.mk config make
- arch/powerpc/cpu/mpc8220/fec_dma_task.S MPC8220 FEC multi-channel dma program
- arch/powerpc/cpu/mpc8220/io.S io functions
- arch/powerpc/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
CONFIG_SYS_MPC8220_CLKIN Define Alaska Input Clock
CONFIG_PSC_CONSOLE Enable MPC8220 UART
CONFIG_EXTUART_CONSOLE Enable External 16552 UART
CONFIG_SYS_AMD_BOOT To determine the u-boot is booted from AMD or Intel
CONFIG_SYS_MBAR MBAR base address
CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.amigaone Normal file
View file

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

53
common/package/boot/uboot-ipq40xx/src/doc/README.arm-caches Normal file
View file

@ -0,0 +1,53 @@
Disabling I-cache:
- Set CONFIG_SYS_ICACHE_OFF
Disabling D-cache:
- Set CONFIG_SYS_DCACHE_OFF
Enabling I-cache:
- Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable().
Enabling D-cache:
- Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable().
Enabling Caches at System Startup:
- Implement enable_caches() for your platform and enable the I-cache and
D-cache from this function. This function is called immediately
after relocation.
Guidelines for Working with D-cache:
Memory to Peripheral DMA:
- Flush the buffer after the MPU writes the data and before the DMA is
initiated.
Peripheral to Memory DMA:
- Invalidate the buffer before starting the DMA. In case there are any dirty
lines from the DMA buffer in the cache, subsequent cache-line replacements
may corrupt the buffer in memory while the DMA is still going on. Cache-line
replacement can happen if the CPU tries to bring some other memory locations
into the cache while the DMA is going on.
- Invalidate the buffer after the DMA is complete and before the MPU reads
it. This may be needed in addition to the invalidation before the DMA
mentioned above, because in some processors memory contents can spontaneously
come to the cache due to speculative memory access by the CPU. If this
happens with the DMA buffer while DMA is going on we have a coherency problem.
Buffer Requirements:
- Any buffer that is invalidated(that is, typically the peripheral to
memory DMA buffer) should be aligned to cache-line boundary both at
at the beginning and at the end of the buffer.
- If the buffer is not cache-line aligned invalidation will be restricted
to the aligned part. That is, one cache-line at the respective boundary
may be left out while doing invalidation.
- A suitable buffer can be alloced on the stack using the
ALLOC_CACHE_ALIGN_BUFFER macro.
Cleanup Before Linux:
- cleanup_before_linux() should flush the D-cache, invalidate I-cache, and
disable MMU and caches.
- The following sequence is advisable while disabling d-cache:
1. disable_dcache() - flushes and disables d-cache
2. invalidate_dcache_all() - invalid any entry that came to the cache
in the short period after the cache was flushed but before the
cache got disabled.

193
common/package/boot/uboot-ipq40xx/src/doc/README.arm-relocation Normal file
View file

@ -0,0 +1,193 @@
To make relocation on arm working, the following changes are done:
At arch level: add linker flag -pie
This causes the linker to generate fixup tables .rel.dyn and .dynsym,
which must be applied to the relocated image before transferring
control to it.
These fixups are described in the ARM ELF documentation as type 23
(program-base-relative) and 2 (symbol-relative)
At cpu level: modify linker file and add a relocation and fixup loop
the linker file must be modified to include the .rel.dyn and .dynsym
tables in the binary image, and to provide symbols for the relocation
code to access these tables
The relocation and fixup loop must be executed after executing
board_init_f at initial location and before executing board_init_r
at final location.
At board level:
dram_init(): bd pointer is now at this point not accessible, so only
detect the real dramsize, and store it in gd->ram_size. Bst detected
with get_ram_size().
TODO: move also dram initialization there on boards where it is possible.
Setup of the the bd_t dram bank info is done in the new function
dram_init_banksize() called after bd is accessible.
At lib level:
Board.c code is adapted from ppc code
* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING *
Boards which are not fixed to support relocation will be REMOVED!
-----------------------------------------------------------------------------
For boards which boot from nand_spl, it is possible to save one copy
if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code
is copied again in relocate_code().
example for the tx25 board:
a) cpu starts
b) it copies the first page in nand to internal ram
(nand_spl_code)
c) end executes this code
d) this initialize CPU, RAM, ... and copy itself to RAM
(this bin must fit in one page, so board_init_f()
don;t fit in it ... )
e) there it copy u-boot to CONFIG_SYS_NAND_U_BOOT_DST and
starts this image @ CONFIG_SYS_NAND_U_BOOT_START
f) u-boot code steps through board_init_f() and calculates
the relocation address and copy itself to it
If CONFIG_SYS_TEXT_BASE == relocation address, the copying of u-boot
in f) could be saved.
-----------------------------------------------------------------------------
TODO
- fill in bd_t infos (check)
- adapt all boards
- maybe adapt CONFIG_SYS_TEXT_BASE (this must be checked from board maintainers)
This *must* be done for boards, which boot from NOR flash
on other boards if CONFIG_SYS_TEXT_BASE = relocation baseaddr, this saves
one copying from u-boot code.
- new function dram_init_banksize() is actual board specific. Maybe
we make a weak default function in arch/arm/lib/board.c ?
-----------------------------------------------------------------------------
Relocation with NAND_SPL (example for the tx25):
- cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE)
and start with code execution on this address.
- The First page contains u-boot code from u-boot:nand_spl/nand_boot_fsl_nfc.c
which inits the dram, cpu registers, reloacte itself to CONFIG_SYS_TEXT_BASE and loads
the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution
@CONFIG_SYS_NAND_U_BOOT_START
- This u-boot does no RAM init, nor CPU register setup. Just look
where it has to copy and relocate itself to this address. If
relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the
CONFIG_SYS_TEXT_BASE from the nand_spl code), then there is no need
to copy, just go on with bss clear and jump to board_init_r.
-----------------------------------------------------------------------------
How ELF relocations 23 and 2 work.
TBC
-------------------------------------------------------------------------------------
Debugging u-boot in RAM:
(example on the qong board)
-----------------
a) start debugger
arm-linux-gdb u-boot
[hs@pollux u-boot]$ arm-linux-gdb u-boot
GNU gdb Red Hat Linux (6.7-2rh)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
The target architecture is set automatically (currently arm)
..
(gdb)
-----------------
b) connect to target
target remote bdi10:2001
(gdb) target remote bdi10:2001
Remote debugging using bdi10:2001
0x8ff17f10 in ?? ()
(gdb)
-----------------
c) discard symbol-file
(gdb) symbol-file
Discard symbol table from `/home/hs/celf/u-boot/u-boot'? (y or n) y
No symbol file now.
(gdb)
-----------------
d) load new symbol table:
(gdb) add-symbol-file u-boot 0x8ff08000
add symbol table from file "u-boot" at
.text_addr = 0x8ff08000
(y or n) y
Reading symbols from /home/hs/celf/u-boot/u-boot...done.
(gdb) c
Continuing.
^C
Program received signal SIGSTOP, Stopped (signal).
0x8ff17f18 in serial_getc () at serial_mxc.c:192
192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY);
(gdb)
add-symbol-file u-boot 0x8ff08000
^^^^^^^^^^
get this address from u-boot bdinfo command
or get it from gd->relocaddr in gdb
=> bdinfo
rch_number = XXXXXXXXXX
boot_params = XXXXXXXXXX
DRAM bank = XXXXXXXXXX
-> start = XXXXXXXXXX
-> size = XXXXXXXXXX
ethaddr = XXXXXXXXXX
ip_addr = XXXXXXXXXX
baudrate = XXXXXXXXXX
TLB addr = XXXXXXXXXX
relocaddr = 0x8ff08000
^^^^^^^^^^
reloc off = XXXXXXXXXX
irq_sp = XXXXXXXXXX
sp start = XXXXXXXXXX
FB base = XXXXXXXXXX
or interrupt execution by any means and re-load the symbols at the location
specified by gd->relocaddr -- this is only valid after board_init_f.
(gdb) set $s = gd->relocaddr
(gdb) symbol-file
(gdb) add-symbol-file u-boot $s
Now you can use gdb as usual :-)

124
common/package/boot/uboot-ipq40xx/src/doc/README.at91 Normal file
View file

@ -0,0 +1,124 @@
Atmel AT91 Evaluation kits
http://atmel.com/dyn/products/tools.asp?family_id=605#1443
I. Board mapping & boot media
------------------------------------------------------------------------------
AT91SAM9260EK, AT91SAM9G20EK & AT91SAM9XEEK
------------------------------------------------------------------------------
Memory map
0x20000000 - 23FFFFFF SDRAM (64 MB)
0xC0000000 - Cxxxxxxx Atmel Dataflash card (J13)
0xD0000000 - Dxxxxxxx Soldered Atmel Dataflash
Environment variables
U-Boot environment variables can be stored at different places:
- Dataflash on SPI chip select 1 (default)
- Dataflash on SPI chip select 0 (dataflash card)
- Nand flash.
You can choose your storage location at config step (here for at91sam9260ek) :
make at91sam9260ek_config - use data flash (spi cs1) (default)
make at91sam9260ek_nandflash_config - use nand flash
make at91sam9260ek_dataflash_cs0_config - use data flash (spi cs0)
make at91sam9260ek_dataflash_cs1_config - use data flash (spi cs1)
------------------------------------------------------------------------------
AT91SAM9261EK, AT91SAM9G10EK
------------------------------------------------------------------------------
Memory map
0x20000000 - 23FFFFFF SDRAM (64 MB)
0xC0000000 - Cxxxxxxx Soldered Atmel Dataflash
0xD0000000 - Dxxxxxxx Atmel Dataflash card (J22)
Environment variables
U-Boot environment variables can be stored at different places:
- Dataflash on SPI chip select 0 (default)
- Dataflash on SPI chip select 3 (dataflash card)
- Nand flash.
You can choose your storage location at config step (here for at91sam9260ek) :
make at91sam9261ek_config - use data flash (spi cs0) (default)
make at91sam9261ek_nandflash_config - use nand flash
make at91sam9261ek_dataflash_cs0_config - use data flash (spi cs0)
make at91sam9261ek_dataflash_cs3_config - use data flash (spi cs3)
------------------------------------------------------------------------------
AT91SAM9263EK
------------------------------------------------------------------------------
Memory map
0x20000000 - 23FFFFFF SDRAM (64 MB)
0xC0000000 - Cxxxxxxx Atmel Dataflash card (J9)
Environment variables
U-Boot environment variables can be stored at different places:
- Dataflash on SPI chip select 0 (dataflash card)
- Nand flash.
- Nor flash (not populate by default)
You can choose your storage location at config step (here for at91sam9260ek) :
make at91sam9263ek_config - use data flash (spi cs0) (default)
make at91sam9263ek_nandflash_config - use nand flash
make at91sam9263ek_dataflash_cs0_config - use data flash (spi cs0)
make at91sam9263ek_norflash_config - use nor flash
You can choose to boot directly from U-Boot at config step
make at91sam9263ek_norflash_boot_config - boot from nor flash
------------------------------------------------------------------------------
AT91SAM9M10G45EK
------------------------------------------------------------------------------
Memory map
0x20000000 - 23FFFFFF SDRAM (64 MB)
0xC0000000 - Cxxxxxxx Atmel Dataflash card (J12)
Environment variables
U-Boot environment variables can be stored at different places:
- Dataflash on SPI chip select 0 (dataflash card)
- Nand flash.
You can choose your storage location at config step (here for at91sam9m10g45ek) :
make at91sam9m10g45ek_config - use data flash (spi cs0) (default)
make at91sam9m10g45ek_nandflash_config - use nand flash
make at91sam9m10g45ek_dataflash_cs0_config - use data flash (spi cs0)
------------------------------------------------------------------------------
AT91SAM9RLEK
------------------------------------------------------------------------------
Memory map
0x20000000 - 23FFFFFF SDRAM (64 MB)
0xC0000000 - Cxxxxxxx Soldered Atmel Dataflash
Environment variables
U-Boot environment variables can be stored at different places:
- Dataflash on SPI chip select 0
- Nand flash.
You can choose your storage location at config step (here for at91sam9260ek) :
make at91sam9263ek_config - use data flash (spi cs0) (default)
make at91sam9263ek_nandflash_config - use nand flash
make at91sam9263ek_dataflash_cs0_config - use data flash (spi cs0)
II. Watchdog support
For security reasons, the at91 watchdog is running at boot time and,
if deactivated, cannot be used anymore.
If you want to use the watchdog, you will need to keep it running in
your code (make sure not to disable it in AT91Bootstrap for instance).
In the U-Boot configuration, the AT91 watchdog support is enabled using
the CONFIG_AT91SAM9_WATCHDOG and CONFIG_HW_WATCHDOG options.

41
common/package/boot/uboot-ipq40xx/src/doc/README.at91-soc Normal file
View file

@ -0,0 +1,41 @@
New C structure AT91 SoC access
=================================
The goal
--------
Currently the at91 arch uses hundreds of address defines and special
at91_xxxx_write/read functions to access the SOC.
The u-boot project perferred method is to access memory mapped hw
regisister via a c structure.
e.g. old
*AT91C_PIOA_IDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
*AT91C_PIOC_PUDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
*AT91C_PIOC_PER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
*AT91C_PIOC_OER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
*AT91C_PIOC_PIO = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
at91_sys_write(AT91_RSTC_CR,
AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
e.g new
pin = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
writel(pin, &pio->pioa.idr);
writel(pin, &pio->pioa.pudr);
writel(pin, &pio->pioa.per);
writel(pin, &pio->pioa.oer);
writel(pin, &pio->pioa.sodr);
writel(AT91_RSTC_KEY | AT91_RSTC_CR_PROCRST |
AT91_RSTC_CR_PERRST, &rstc->cr);
The method for updating
------------------------
1. add's the temporary CONFIG_AT91_LEGACY to all at91 board configs
2. Display a compile time warning, if the board has not been converted
3. add new structures for SoC access
4. Convert arch, driver and boards file to new SoC
5. remove legacy code, if all boards and drives are ready

77
common/package/boot/uboot-ipq40xx/src/doc/README.atmel_mci Normal file
View file

@ -0,0 +1,77 @@
How to use SD/MMC cards with Atmel SoCs having MCI hardware
-----------------------------------------------------------
2010-08-16 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
This is a new approach to use Atmel MCI hardware with the
general MMC framework. Therefore it benefits from that
framework's abilities to handle SDHC Cards and the ability
to write blocks.
- AT91SAM9XE512 (tested, will definitely work with XE128 and XE256)
- AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
- AT91SAM9G20 (not tested, should work)
It should work with all other ATMEL devices that have MCI,
including AVR32.
The generic driver does NOT assign port pins to the MCI block
nor does it start the MCI clock. This has to be handled in a
board/SoC specific manner before the driver is initialized:
example: this is added to at91sam9260_devices.c:
#if defined(CONFIG_GENERIC_ATMEL_MCI)
void at91_mci_hw_init(void)
{
at91_set_a_periph(AT91_PIO_PORTA, 8, PUP); /* MCCK */
#if defined(CONFIG_ATMEL_MCI_PORTB)
at91_set_b_periph(AT91_PIO_PORTA, 1, PUP); /* MCCDB */
at91_set_b_periph(AT91_PIO_PORTA, 0, PUP); /* MCDB0 */
at91_set_b_periph(AT91_PIO_PORTA, 5, PUP); /* MCDB1 */
at91_set_b_periph(AT91_PIO_PORTA, 4, PUP); /* MCDB2 */
at91_set_b_periph(AT91_PIO_PORTA, 3, PUP); /* MCDB3 */
#else
at91_set_a_periph(AT91_PIO_PORTA, 7, PUP); /* MCCDA */
at91_set_a_periph(AT91_PIO_PORTA, 6, PUP); /* MCDA0 */
at91_set_a_periph(AT91_PIO_PORTA, 9, PUP); /* MCDA1 */
at91_set_a_periph(AT91_PIO_PORTA, 10, PUP); /* MCDA2 */
at91_set_a_periph(AT91_PIO_PORTA, 11, PUP); /* MCDA3 */
#endif
}
#endif
the board specific file need added:
...
#ifdef CONFIG_GENERIC_ATMEL_MCI
# include <mmc.h>
#endif
...
#ifdef CONFIG_GENERIC_ATMEL_MCI
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI);
at91_mci_hw_init();
/* This calls the atmel_mci_init in gen_atmel_mci.c */
return atmel_mci_init((void *)AT91_BASE_MCI);
}
/* this is a weak define that we are overriding */
int board_mmc_getcd(struct mmc *mmc)
{
return !at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN);
}
#endif
and the board definition files needs:
/* SD/MMC card */
#define CONFIG_MMC 1
#define CONFIG_GENERIC_MMC 1
#define CONFIG_GENERIC_ATMEL_MCI 1
#define CONFIG_ATMEL_MCI_PORTB 1 /* Atmel XE-EK uses port B */
#define CONFIG_SYS_MMC_CD_PIN AT91_PIN_PC9
#define CONFIG_CMD_MMC 1

165
common/package/boot/uboot-ipq40xx/src/doc/README.autoboot Normal file
View file

@ -0,0 +1,165 @@
/*
* (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.
Note that CONFIG_AUTOBOOT_PROMPT is used as the (only)
argument to a printf() call, so it may contain '%' format
specifications, provided that it also includes, sepearated by
commas exactly like in a printf statement, the required
arguments. It is the responsibility of the user to select only
such arguments that are valid in the given context. A
reasonable prompt could be defined as
#define CONFIG_AUTOBOOT_PROMPT \
"autoboot in %d seconds\n",bootdelay
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.

77
common/package/boot/uboot-ipq40xx/src/doc/README.bamboo Normal file
View file

@ -0,0 +1,77 @@
The 2 important dipswitches are configured as shown below:
SW1 (for 33MHz SysClk)
----------------------
S1 S2 S3 S4 S5 S6 S7 S8
OFF OFF OFF OFF OFF OFF OFF ON
SW7 (for Op-Code Flash and Boot Option H)
-----------------------------------------
S1 S2 S3 S4 S5 S6 S7 S8
OFF OFF OFF ON OFF OFF OFF OFF
The EEPROM at location 0x52 is loaded with these 16 bytes:
C47042A6 05D7A190 40082350 0d050000
SDR0_SDSTP0[ENG]: 1 : PLL's VCO is the source for PLL forward divisors
SDR0_SDSTP0[SRC]: 1 : Feedback originates from PLLOUTB
SDR0_SDSTP0[SEL]: 0 : Feedback selection is PLL output
SDR0_SDSTP0[TUNE]: 1000111000 : 10 <= M <= 22, 600MHz < VCO <= 900MHz
SDR0_SDSTP0[FBDV]: 4 : PLL feedback divisor
SDR0_SDSTP0[FBDVA]: 2 : PLL forward divisor A
SDR0_SDSTP0[FBDVB]: 5 : PLL forward divisor B
SDR0_SDSTP0[PRBDV0]: 1 : PLL primary divisor B
SDR0_SDSTP0[OPBDV0]: 2 : OPB clock divisor
SDR0_SDSTP0[LFBDV]: 1 : PLL local feedback divisor
SDR0_SDSTP0[PERDV0]: 3 : Peripheral clock divisor 0
SDR0_SDSTP0[MALDV0]: 2 : MAL clock divisor 0
SDR0_SDSTP0[PCIDV0]: 2 : Sync PCI clock divisor 0
SDR0_SDSTP0[PLLTIMER]: 7 : PLL locking timer
SDR0_SDSTP0[RW]: 1 : EBC ROM width: 16-bit
SDR0_SDSTP0[RL]: 0 : EBC ROM location: EBC
SDR0_SDSTP0[PAE]: 0 : PCI internal arbiter: disabled
SDR0_SDSTP0[PHCE]: 0 : PCI host configuration: disabled
SDR0_SDSTP0[ZM]: 3 : ZMII mode: RMII mode 100
SDR0_SDSTP0[CTE]: 0 : CPU trace: disabled
SDR0_SDSTP0[Nto1]: 0 : CPU/PLB ratio N/P: not N to 1
SDR0_SDSTP0[PAME]: 1 : PCI asynchronous mode: enabled
SDR0_SDSTP0[MEM]: 1 : Multiplex: EMAC
SDR0_SDSTP0[NE]: 0 : NDFC: disabled
SDR0_SDSTP0[NBW]: 0 : NDFC boot width: 8-bit
SDR0_SDSTP0[NBW]: 0 : NDFC boot page selection
SDR0_SDSTP0[NBAC]: 0 : NDFC boot address selection cycle: 3 Addr. Cycles, 1 Col. + 2 Row (512 page size)
SDR0_SDSTP0[NARE]: 0 : NDFC auto read : disabled
SDR0_SDSTP0[NRB]: 0 : NDFC Ready/Busy : Ready
SDR0_SDSTP0[NDRSC]: 33333 : NDFC device reset counter
SDR0_SDSTP0[NCG0]: 0 : NDFC/EBC chip select gating CS0 : EBC
SDR0_SDSTP0[NCG1]: 0 : NDFC/EBC chip select gating CS1 : EBC
SDR0_SDSTP0[NCG2]: 0 : NDFC/EBC chip select gating CS2 : EBC
SDR0_SDSTP0[NCG3]: 0 : NDFC/EBC chip select gating CS3 : EBC
SDR0_SDSTP0[NCRDC]: 3333 : NDFC device read count
PPC440EP Clocking Configuration
SysClk is 33.0MHz, M is 20, VCO is 660.0MHz, CPU is 330.0MHz, PLB is 132.0MHz
OPB is 66.0MHz, EBC is 44.0MHz, MAL is 66.0MHz, Sync PCI is 66.0MHz
The above information is reported by Eugene O'Brien
<Eugene.O'Brien@advantechamt.com>. Thanks a lot.
2007-08-06, Stefan Roese <sr@denx.de>
---------------------------------------------------------------------
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>

78
common/package/boot/uboot-ipq40xx/src/doc/README.bedbug Normal file
View file

@ -0,0 +1,78 @@
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.
./arch/powerpc/cpu/ppc4xx/Makefile
Added bedbug_405.c to the Makefile.
./arch/powerpc/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.
./arch/powerpc/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/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.
./arch/powerpc/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.
arch/powerpc/cpu/mpc8xx/Makefile
Added new file "bedbug_860.c" to the makefile
arch/powerpc/cpu/mpc8xx/start.S
Added handler for InstructionBreakpoint (0xfd00)
arch/powerpc/cpu/mpc8xx/traps.c
Added new routine DebugException()
New Files:
arch/powerpc/cpu/mpc8xx/bedbug_860.c
CPU-specific routines for 860 debug registers.

56
common/package/boot/uboot-ipq40xx/src/doc/README.bitbangMII Normal file
View file

@ -0,0 +1,56 @@
This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
support an arbitrary number of mii buses. This feature is useful when your
board uses different mii buses for different phys and all (or a part) of these
buses are implemented via bit-banging mode.
The driver requires that the following macros should be defined into the board
configuration file:
CONFIG_BITBANGMII - Enable the miiphybb driver
CONFIG_BITBANGMII_MULTI - Enable the multi bus support
If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs
to define at least the following macros:
MII_INIT - Generic code to enable the MII bus (optional)
MDIO_DECLARE - Declaration needed to access to the MDIO pin (optional)
MDIO_ACTIVE - Activate the MDIO pin as out pin
MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin
MDIO_READ - Read the MDIO pin
MDIO(v) - Write v on the MDIO pin
MDC_DECLARE - Declaration needed to access to the MDC pin (optional)
MDC(v) - Write v on the MDC pin
The previous macros make the driver compatible with the previous version
(that didn't support the multi-bus).
When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill
the bb_miiphy_buses[] array with a record for each required bus and declare
the bb_miiphy_buses_num variable with the number of mii buses.
The record (struct bb_miiphy_bus) has the following fields/callbacks (see
miiphy.h for details):
char name[] - The symbolic name that must be equal to the MII bus
registered name
int (*init)() - Initialization function called at startup time (just
before the Ethernet initialization)
int (*mdio_active)() - Activate the MDIO pin as output
int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin
int (*set_mdio)() - Write the MDIO pin
int (*get_mdio)() - Read the MDIO pin
int (*set_mdc)() - Write the MDC pin
int (*delay)() - Delay function
void *priv - Private data used by board specific code
The board code will look like:
struct bb_miiphy_bus bb_miiphy_buses[] = {
{ .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... },
{ .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... },
...
};
int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) /
sizeof(bb_miiphy_buses[0]);
2009 Industrie Dial Face S.p.A.
Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>

46
common/package/boot/uboot-ipq40xx/src/doc/README.blackfin Normal file
View file

@ -0,0 +1,46 @@
Notes for the Blackfin architecture port of Das U-Boot
=========
! ABOUT !
=========
<marketing blurb>
Blackfin Processors embody a new breed of 16/32-bit embedded processor, ideally
suited for products where a convergence of capabilities are necessary -
multi-format audio, video, voice and image processing; multi-mode baseband and
packet processing; control processing; and real-time security. The Blackfin's
unique combination of software flexibility and scalability has gained it
widespread adoption in convergent applications.
</marketing blurb>
The Blackfin processor is wholly developed by Analog Devices Inc.
===========
! SUPPORT !
===========
All open source code for the Blackfin processors are being handled via our
collaborative website:
http://blackfin.uclinux.org/
In particular, bug reports, feature requests, help etc... for Das U-Boot are
handled in the Das U-Boot sub project:
http://blackfin.uclinux.org/gf/project/u-boot
This website is backed both by an open source community as well as a dedicated
team from Analog Devices Inc.
=============
! TOOLCHAIN !
=============
To compile the Blackfin aspects, you'll need the GNU toolchain configured for
the Blackfin processor. You can obtain such a cross-compiler here:
http://blackfin.uclinux.org/gf/project/toolchain
=================
! DOCUMENTATION !
=================
For Blackfin specific documentation, you can visit our dedicated doc wiki:
http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot

84
common/package/boot/uboot-ipq40xx/src/doc/README.bus_vcxk Normal file
View file

@ -0,0 +1,84 @@
/*
* (C) Copyright 2008-2009
* BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de>
* Jens Scharsig <esw@bus-elektronik.de>
*
* 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 vcxk video controller driver
======================================
By defining CONFIG_VIDEO_VCXK this driver can be used with VC2K, VC4K and
VC8K devices on following boards:
board | ARCH | Vendor
-----------------------------------------------------------------------
EB+CPU5282-T1 | MCF5282 | BuS Elektronik GmbH & Co. KG
EB+MCF-EVB123 | MCF5282 | BuS Elektronik GmbH & Co. KG
EB+CPUx9K2 | AT91RM9200 | BuS Elektronik GmbH & Co. KG
ZLSA | AT91RM9200 | Ruf Telematik AG
Driver configuration
--------------------
The driver needs some defines to describe the target hardware:
CONFIG_SYS_VCXK_BASE
base address of VCxK hardware memory
CONFIG_SYS_VCXK_DEFAULT_LINEALIGN
defines the physical alignment of a pixel row
CONFIG_SYS_VCXK_DOUBLEBUFFERED
some boards that use vcxk prevent read from framebuffer memory.
define this option to enable double buffering (needs 16KiB RAM)
CONFIG_SYS_VCXK_<xxxx>_PIN
defines the number of the I/O line PIN in the port
valid values for <xxxx> are:
ACKNOWLEDGE
describes the acknowledge line from vcxk hardware
ENABLE
describes the enable line to vcxk hardware
INVERT
describes the invert line to vcxk hardware
RESET
describes the reset line to vcxk hardware
REQUEST
describes the request line to vcxk hardware
CONFIG_SYS_VCXK_<xxxx>_PORT
defines the I/O port which is connected with the line
for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN
CONFIG_SYS_VCXK_<xxxx>_DDR
defines the register which configures the direction
for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN

29
common/package/boot/uboot-ipq40xx/src/doc/README.cfi Normal file
View file

@ -0,0 +1,29 @@
The common CFI driver provides this weak default implementation for
flash_cmd_reset():
void __flash_cmd_reset(flash_info_t *info)
{
/*
* We do not yet know what kind of commandset to use, so we issue
* the reset command in both Intel and AMD variants, in the hope
* that AMD flash roms ignore the Intel command.
*/
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
}
void flash_cmd_reset(flash_info_t *info)
__attribute__((weak,alias("__flash_cmd_reset")));
Some flash chips seems to have trouble with this reset sequence. In this case
the board specific code can override this weak default version with a board
specific function. For example the digsy_mtc board equipped with the M29W128GH
from Numonyx needs this version to function properly:
void flash_cmd_reset(flash_info_t *info)
{
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
}
see also:
http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html

84
common/package/boot/uboot-ipq40xx/src/doc/README.cmi Normal file
View file

@ -0,0 +1,84 @@
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 CONFIG_SYS_SDRAM_BASE
:
0x000F 9FFF
:
:
0x0100 0000 CONFIG_SYS_IMMR (Internal memory map base adress)
:
0x0130 7FFF
:
:
0x0200 0000 CONFIG_SYS_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
common/package/boot/uboot-ipq40xx/src/doc/README.commands Normal file
View file

@ -0,0 +1,31 @@
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 maximum number of arguments this function takes
repeatable: either 0 or 1 to indicate if autorepeat is allowed
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
**** Behind 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
common/package/boot/uboot-ipq40xx/src/doc/README.commands.itest Normal file
View file

@ -0,0 +1,16 @@
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; ....

31
common/package/boot/uboot-ipq40xx/src/doc/README.commands.spl Normal file
View file

@ -0,0 +1,31 @@
The spl command is used to export a boot parameter image to RAM. Later
it may implement more functions connected to the SPL.
SUBCOMMAND EXPORT
To execute the command everything has to be in place as if bootm should be
used. (kernel image, initrd-image, fdt-image etc.)
export has two subcommands:
atags: exports the ATAGS
fdt: exports the FDT
Call is:
spl export <ftd|atags> [kernel_addr] [initrd_addr] [fdt_addr if fdt]
TYPICAL CALL
on OMAP3:
nandecc hw
nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/
spl export atags /* export ATAGS */
nand erase 0x680000 0x20000 /* erase - one page */
nand write 0x80000100 0x680000 0x20000 /* write the image - one page */
call with FDT:
nandecc hw
nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/
tftpboot 0x80000100 devkit8000.dtb /* Read fdt */
spl export fdt 0x82000000 - 0x80000100 /* export FDT */
nand erase 0x680000 0x20000 /* erase - one page */
nand write <adress shown by spl export> 0x680000 0x20000

118
common/package/boot/uboot-ipq40xx/src/doc/README.console Normal file
View file

@ -0,0 +1,118 @@
/*
* (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 arch/*/lib/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

159
common/package/boot/uboot-ipq40xx/src/doc/README.davinci Normal file
View file

@ -0,0 +1,159 @@
Summary
=======
This README is about U-Boot support for TI's ARM 926EJS based family of SoCs.
These SOCs are used for cameras, video security and surveillance, DVR's, etc.
DaVinci SOC's comprise of DM644x, DM646x, DM35x and DM36x series of SOC's
Additionally there are some SOCs meant for the audio market which though have
an OMAP part number are very similar to the DaVinci series of SOC's
Additionally, some family members contain a TI DSP and/or graphics
co processors along with a host of other peripherals.
Currently the following boards are supported:
* TI DaVinci DM644x EVM
* TI DaVinci DM646x EVM
* TI DaVinci DM355 EVM
* TI DaVinci DM365 EVM
* TI DA830 EVM
* TI DA850 EVM
* DM355 based Leopard board
* DM644x based schmoogie board
* DM644x based sffsdr board
* DM644x based sonata board
Build
=====
* TI DaVinci DM644x EVM:
make davinci_dvevm_config
make
* TI DaVinci DM646x EVM:
make davinci_dm6467evm_config
make
* TI DaVinci DM355 EVM:
make davinci_dm355evm_config
make
* TI DaVinci DM365 EVM:
make davinci_dm365evm_config
make
* TI DA830 EVM:
make da830evm_config
make
* TI DA850 EVM:
make da850evm_config
make
* DM355 based Leopard board:
make davinci_dm355leopard_config
make
* DM644x based schmoogie board:
make davinci_schmoogie_config
make
* DM644x based sffsdr board:
make davinci_sffsdr_config
make
* DM644x based sonata board:
make davinci_sonata_config
make
Bootloaders
===============
The DaVinci SOC's use 2 bootloaders. The low level initialization
is done by a UBL(user boot loader). The UBL is written to a NAND/NOR/SPI flash
by a programmer. During initial bootup, the ROM Bootloader reads the UBL
from a storage device and loads it into the IRAM. The UBL then loads the U-Boot
into the RAM.
The programmers and UBL are always released as part of any standard TI
software release associated with an SOC.
Alternative boot method (DA850 EVM only):
For the DA850 EVM an SPL (secondary program loader, see doc/README.SPL)
is provided to load U-Boot directly from SPI flash. In this case, the
SPL does the low level initialization that is otherwise done by the SPL.
To build U-Boot with this SPL, do
make da850evm_config
make u-boot.ais
and program the resulting u-boot.ais file to the SPI flash of the DA850 EVM.
Environment Variables
=====================
The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
silicon, in Hz, via an environment variable "maxcpuclk".
The maximum clock rate allowed depends on the silicon populated on the EVM.
Please make sure you understand the restrictions placed on this clock in the
device specific datasheet before setting up this variable. This information is
passed to the Linux kernel using the ATAG_REVISION atag.
If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
is used to obtain this information.
Links
=====
1) TI DaVinci DM355 EVM:
http://focus.ti.com/docs/prod/folders/print/tms320dm355.html
http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=203&osCsid=c499af6087317f11b3da19b4e8f1af32
2) TI DaVinci DM365 EVM:
http://focus.ti.com/docs/prod/folders/print/tms320dm365.html?247SEM=
http://support.spectrumdigital.com/boards/evmdm365/revc/
3) DaVinci DM355 based leopard board
http://designsomething.org/leopardboard/default.aspx
http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=192&osCsid=67c20335668ffc57cb35727106eb24b1
4) TI DaVinci DM6467 EVM:
http://focus.ti.com/docs/prod/folders/print/tms320dm6467.html
http://support.spectrumdigital.com/boards/evmdm6467/revf/
5) TI DaVinci DM6446 EVM:
http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html
http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=222
6) TI DA830 EVM
http://focus.ti.com/apps/docs/gencontent.tsp?appId=1&contentId=52385
http://www.spectrumdigital.com/product_info.php?cPath=37&products_id=214
7) TI DA850 EVM
http://focus.ti.com/docs/prod/folders/print/omap-l138.html
http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit
Davinci special defines
=======================
CONFIG_SYS_DV_NOR_BOOT_CFG: AM18xx based boards, booting in NOR Boot mode
need a "NOR Boot Configuration Word" stored
in the NOR Flash. This define adds this.
More Info about this, see:
spraba5a.pdf chapter 3.1

141
common/package/boot/uboot-ipq40xx/src/doc/README.davinci.nand_spl Normal file
View file

@ -0,0 +1,141 @@
With this approach, we don't need the UBL any more on DaVinci boards.
A "make boardname" will compile a u-boot.ubl, with UBL Header, which is
needed for the RBL to find the "UBL", which actually is a UBL-compatible
header, nand spl code and u-boot code.
As the RBL uses another read function as the "standard" u-boot,
we need a command, which switches between this two read/write
functions, so we can write the UBL header and the spl
code in a format, which the RBL can read. This is realize
(at the moment in board specific code) in the u-boot command
nandrbl
nandrbl without arguments returns actual mode (rbl or uboot).
with nandrbl mode (mode = "rbl" or "uboot") you can switch
between the two NAND read/write modes.
To set up mkimage you need a config file for mkimage, example:
board/ait/cam_enc_4xx/ublimage.cfg
For information about the configuration please see:
doc/README.ublimage
Example for the cam_enc_4xx board:
On the cam_enc_4xx board we have a NAND flash with blocksize = 0x20000 and
pagesize = 0x800, so the u-boot.ubl image (which you get with:
"make cam_enc_4xx") looks like this:
00000000 00 ed ac a1 20 00 00 00 06 00 00 00 05 00 00 00 |.... ...........|
00000010 00 00 00 00 20 00 00 00 ff ff ff ff ff ff ff ff |.... ...........|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000800 14 00 00 ea 14 f0 9f e5 10 f0 9f e5 0c f0 9f e5 |................|
00000810 08 f0 9f e5 04 f0 9f e5 00 f0 9f e5 04 f0 1f e5 |................|
00000820 00 01 00 00 78 56 34 12 78 56 34 12 78 56 34 12 |....xV4.xV4.xV4.|
[...]
*
00001fe0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00001ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00003800 14 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
00003810 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
00003820 80 01 08 81 e0 01 08 81 40 02 08 81 a0 02 08 81 |........@.......|
In the first "page" of the image, we have the UBL Header, needed for
the RBL to find the spl code.
The spl code starts in the second "page" of the image, with a size
defined by:
#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
After the spl code, there comes the "real" u-boot code
@ (6 + 1) * pagesize = 0x3800
------------------------------------------------------------------------
Setting up spl code:
/*
* RBL searches from Block n (n = 1..24)
* so we can define, how many UBL Headers
* we write before the real spl code
*/
#define CONFIG_SYS_NROF_UBL_HEADER 5
#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
#define CONFIG_SYS_NAND_U_BOOT_OFFS ((CONFIG_SYS_NROF_UBL_HEADER * \
CONFIG_SYS_NAND_BLOCK_SIZE) + \
(CONFIG_SYS_NROF_PAGES_NAND_SPL) * \
CONFIG_SYS_NAND_PAGE_SIZE)
------------------------------------------------------------------------
Burning into NAND:
step 1:
The RBL searches from Block n ( n = 1..24) on page 0 for valid UBL
Headers, so you have to burn the UBL header page from the u-boot.ubl
image to the blocks, you want to have the UBL header.
!! Don;t forget to switch to rbl nand read/write functions with
"nandrbl rbl"
step 2:
You need to setup in the ublimage.cfg, where the RBL can find the spl
code, and how big it is.
!! RBL always starts reading from page 0 !!
For the AIT board, we have:
PAGES 6
START_BLOCK 5
So we need to copy the spl code to block 5 page 0
!! Don;t forget to switch to rbl nand read/write functions with
"nandrbl rbl"
step 3:
You need to copy the u-boot image to the block/page
where the spl code reads it (CONFIG_SYS_NAND_U_BOOT_OFFS)
!! Don;t forget to switch to rbl nand read/write functions with
"nandrbl uboot", which is default.
On the cam_enc_4xx board it is:
#define CONFIG_SYS_NAND_U_BOOT_OFFS (0xc0000)
-> this results in following NAND usage on the cam_enc_4xx board:
addr
20000 possible UBL Header
40000 possible UBL Header
60000 possible UBL Header
80000 possilbe UBL Header
a0000 spl code
c0000 u-boot code
The above steps are executeed through the following environment vars:
(using 80000 as address for the UBL header)
pagesz=800
uboot=/tftpboot/cam_enc_4xx/u-boot.ubl
load=tftp 80000000 ${uboot}
writeheader nandrbl rbl;nand erase 80000 ${pagesz};nand write 80000000 80000 ${pagesz};nandrbl uboot
writenand_spl nandrbl rbl;nand erase a0000 3000;nand write 80000800 a0000 3000;nandrbl uboot
writeuboot nandrbl uboot;nand erase c0000 5d000;nand write 80003800 c0000 5d000
update=run load writeheader writenand_spl writeuboot
If you do a "run load update" u-boot, spl + ubl header
are magically updated ;-)
Note:
- There seem to be a bug in the RBL code (at least on my HW),
In the UBL block, I can set the page to values != 0, so it
is possible to burn step 1 and step 2 in one step into the
flash, but the RBL ignores the page settings, so I have to
burn the UBL Header to a page 0 and the spl code to
a page 0 ... :-(
- If we make the nand read/write functions in the RBL equal to
the functions in u-boot (as I have no RBL code, it is only
possible in u-boot), we could burn the complete image in
one step ... that would be nice ...

105
common/package/boot/uboot-ipq40xx/src/doc/README.db64360 Normal file
View file

@ -0,0 +1,105 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.db64460 Normal file
View file

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

25
common/package/boot/uboot-ipq40xx/src/doc/README.designware_eth Normal file
View file

@ -0,0 +1,25 @@
This driver supports Designware Ethernet Controller provided by Synopsis.
The driver is enabled by CONFIG_DESIGNWARE_ETH.
The driver has been developed and tested on SPEAr platforms. By default, the
MDIO interface works at 100/Full. #defining the below options in board
configuration file changes this behavior.
Call an subroutine from respective board/.../board.c
designware_initialize(u32 id, ulong base_addr, u32 phy_addr);
The various options suported by the driver are
1. CONFIG_DW_ALTDESCRIPTOR
Define this to use the Alternate/Enhanced Descriptor configurations.
1. CONFIG_DW_AUTONEG
Define this to autonegotiate with the host before proceeding with mac
level configuration. This obviates the definitions of CONFIG_DW_SPEED10M
and CONFIG_DW_DUPLEXHALF.
2. CONFIG_DW_SPEED10M
Define this to change the default behavior from 100Mbps to 10Mbps.
3. CONFIG_DW_DUPLEXHALF
Define this to change the default behavior from Full Duplex to Half.
4. CONFIG_DW_SEARCH_PHY
Define this to search the phy address. This would overwrite the value
passed as 3rd arg from designware_initialize routine.

67
common/package/boot/uboot-ipq40xx/src/doc/README.dnp5370 Normal file
View file

@ -0,0 +1,67 @@
This document describes the board support for
Dil/NetPC DNP/5370 (http://www.dilnetpc.com/dnp0086.htm) module.
The distributor is SSV (http://www.ssv-embedded.de),
The module used to develop the support files contains:
* Processor: Blackfin BF537 Rev 0.3 (600 MHz core / 120MHz RAM)
* RAM: 32 MB SDRAM
Hynix HY57V561620FTP-H 810EA
Connected to Blackfin via "Expansion Bus"
Address range 0x0000.0000 - 0x1fff.ffff
* NOR flash: 32 MBit (4 MByte)
Exel Semiconductor ES29LVS320EB
Connected to Blackfin via "Expansion Bus",
Chip Selects 0, 1 and 2, each is connected
to a 1 MB memory bank at Blackfin, therefore
only 3 MB accessible.
Address range 0x2000.0000 - 0x202f.ffff
CFI compatible
Exel Semiconductor was bought by Rohm Semiconductor (www.rohm.com).
* NAND flash: 64 MBit (8 MByte)
Atmel 45DB642D-CNU
Connected to Blackfin via SPI
CFI compatible
* Davicom DM9161EP Ethernet PHY
* A SD card reader, connected via SPI
* Hardware watchdog MAX823 or TPS3823
(other devices not listed here)
To run it, the module must be inserted in a 64 pin DIL socket
on another board, e.g. DNP/EVA13 (together: SSV SK28).
The Blackfin is booted from NOR flash. The NOR flash data begins
with the U-Boot code and is then followed by the Linux code.
Finally, the MAC is stored in the last sector.
You may need to adjust these settings to your needs.
The memory map used to develop the board support is:
Memory map:
0x00000000 .. 0x01ffffff SDRAM
0x20000000 .. 0x202fffff NOR flash
RAM use:
0x01f9bffc .. 0x01fbbffb U-Boot stack
0x01f9c000 .. 0x01f9ffff U-Boot global data
0x01fa0000 .. 0x01fbffff U-Boot malloc() RAM
0x01fc0000 .. 0x01ffffff U-Boot execution RAM
NOR flash use:
0x20000000 .. 0x0002ffff U-Boot
0x20004000 .. 0x20005fff U-Boot environment
0x20030000 .. 0x202effff Linux kernel image
0x202f0000 .. 0x202fffff MAC address sector
NOR flash is 0x00300000 (3145728) bytes large (3 MB).
Max space for compressed kernel in flash is 0x002c0000 (2883584) bytes (2.75 MB)
Max space for u-boot in flash is 0x00030000 (196608) bytes (192 KB)
The module is hardwired to BYPASS boot mode.

62
common/package/boot/uboot-ipq40xx/src/doc/README.dns Normal file
View file

@ -0,0 +1,62 @@
Domain Name System
-------------------------------------------
The Domain Name System (DNS) is a hierarchical naming system for computers,
services, or any resource participating in the Internet. It associates various
information with domain names assigned to each of the participants. Most
importantly, it translates domain names meaningful to humans into the numerical
(binary) identifiers associated with networking equipment for the purpose of
locating and addressing these devices world-wide. An often used analogy to
explain the Domain Name System is that it serves as the "phone book" for the
Internet by translating human-friendly computer hostnames into IP addresses.
For example, www.example.com translates to 208.77.188.166.
For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
U-Boot and DNS
------------------------------------------
CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
will send name lookups to the dns server (env var 'dnsip')
Turning this option on will about abou 1k to U-Boot's size.
Example:
bfin> print dnsip
dnsip=192.168.0.1
bfin> dns www.google.com
66.102.1.104
By default, dns does nothing except print the IP number on
the default console - which by itself, would be pretty
useless. Adding a third argument to the dns command will
use that as the environment variable to be set.
Example:
bfin> print googleip
## Error: "googleip" not defined
bfin> dns www.google.com googleip
64.233.161.104
bfin> print googleip
googleip=64.233.161.104
bfin> ping ${googleip}
Using Blackfin EMAC device
host 64.233.161.104 is alive
In this way, you can lookup, and set many more meaningful
things.
bfin> sntp
ntpserverip not set
bfin> dns pool.ntp.org ntpserverip
72.18.205.156
bfin> sntp
Date: 2009-07-18 Time: 4:06:57
For some helpful things that can be related to DNS in U-Boot,
look at the top level README for these config options:
CONFIG_CMD_DHCP
CONFIG_BOOTP_DNS
CONFIG_BOOTP_DNS2

190
common/package/boot/uboot-ipq40xx/src/doc/README.drivers.eth Normal file
View file

@ -0,0 +1,190 @@
-----------------------
Ethernet Driver Guide
-----------------------
The networking stack in Das U-Boot is designed for multiple network devices
to be easily added and controlled at runtime. This guide is meant for people
who wish to review the net driver stack with an eye towards implementing your
own ethernet device driver. Here we will describe a new pseudo 'APE' driver.
------------------
Driver Functions
------------------
All functions you will be implementing in this document have the return value
meaning of 0 for success and non-zero for failure.
----------
Register
----------
When U-Boot initializes, it will call the common function eth_initialize().
This will in turn call the board-specific board_eth_init() (or if that fails,
the cpu-specific cpu_eth_init()). These board-specific functions can do random
system handling, but ultimately they will call the driver-specific register
function which in turn takes care of initializing that particular instance.
Keep in mind that you should code the driver to avoid storing state in global
data as someone might want to hook up two of the same devices to one board.
Any such information that is specific to an interface should be stored in a
private, driver-defined data structure and pointed to by eth->priv (see below).
So the call graph at this stage would look something like:
board_init()
eth_initialize()
board_eth_init() / cpu_eth_init()
driver_register()
initialize eth_device
eth_register()
At this point in time, the only thing you need to worry about is the driver's
register function. The pseudo code would look something like:
int ape_register(bd_t *bis, int iobase)
{
struct ape_priv *priv;
struct eth_device *dev;
priv = malloc(sizeof(*priv));
if (priv == NULL)
return 1;
dev = malloc(sizeof(*dev));
if (dev == NULL) {
free(priv);
return 1;
}
/* setup whatever private state you need */
memset(dev, 0, sizeof(*dev));
sprintf(dev->name, "APE");
/* if your device has dedicated hardware storage for the
* MAC, read it and initialize dev->enetaddr with it
*/
ape_mac_read(dev->enetaddr);
dev->iobase = iobase;
dev->priv = priv;
dev->init = ape_init;
dev->halt = ape_halt;
dev->send = ape_send;
dev->recv = ape_recv;
dev->write_hwaddr = ape_write_hwaddr;
eth_register(dev);
#ifdef CONFIG_CMD_MII)
miiphy_register(dev->name, ape_mii_read, ape_mii_write);
#endif
return 1;
}
The exact arguments needed to initialize your device are up to you. If you
need to pass more/less arguments, that's fine. You should also add the
prototype for your new register function to include/netdev.h.
The return value for this function should be as follows:
< 0 - failure (hardware failure, not probe failure)
>=0 - number of interfaces detected
You might notice that many drivers seem to use xxx_initialize() rather than
xxx_register(). This is the old naming convention and should be avoided as it
causes confusion with the driver-specific init function.
Other than locating the MAC address in dedicated hardware storage, you should
not touch the hardware in anyway. That step is handled in the driver-specific
init function. Remember that we are only registering the device here, we are
not checking its state or doing random probing.
-----------
Callbacks
-----------
Now that we've registered with the ethernet layer, we can start getting some
real work done. You will need five functions:
int ape_init(struct eth_device *dev, bd_t *bis);
int ape_send(struct eth_device *dev, volatile void *packet, int length);
int ape_recv(struct eth_device *dev);
int ape_halt(struct eth_device *dev);
int ape_write_hwaddr(struct eth_device *dev);
The init function checks the hardware (probing/identifying) and gets it ready
for send/recv operations. You often do things here such as resetting the MAC
and/or PHY, and waiting for the link to autonegotiate. You should also take
the opportunity to program the device's MAC address with the dev->enetaddr
member. This allows the rest of U-Boot to dynamically change the MAC address
and have the new settings be respected.
The send function does what you think -- transmit the specified packet whose
size is specified by length (in bytes). You should not return until the
transmission is complete, and you should leave the state such that the send
function can be called multiple times in a row.
The recv function should process packets as long as the hardware has them
readily available before returning. i.e. you should drain the hardware fifo.
For each packet you receive, you should call the NetReceive() function on it
along with the packet length. The common code sets up packet buffers for you
already in the .bss (NetRxPackets), so there should be no need to allocate your
own. This doesn't mean you must use the NetRxPackets array however; you're
free to call the NetReceive() function with any buffer you wish. So the pseudo
code here would look something like:
int ape_recv(struct eth_device *dev)
{
int length, i = 0;
...
while (packets_are_available()) {
...
length = ape_get_packet(&NetRxPackets[i]);
...
NetReceive(&NetRxPackets[i], length);
...
if (++i >= PKTBUFSRX)
i = 0;
...
}
...
return 0;
}
The halt function should turn off / disable the hardware and place it back in
its reset state. It can be called at any time (before any call to the related
init function), so make sure it can handle this sort of thing.
The write_hwaddr function should program the MAC address stored in dev->enetaddr
into the Ethernet controller.
So the call graph at this stage would look something like:
some net operation (ping / tftp / whatever...)
eth_init()
dev->init()
eth_send()
dev->send()
eth_rx()
dev->recv()
eth_halt()
dev->halt()
-----------------------------
CONFIG_MII / CONFIG_CMD_MII
-----------------------------
If your device supports banging arbitrary values on the MII bus (pretty much
every device does), you should add support for the mii command. Doing so is
fairly trivial and makes debugging mii issues a lot easier at runtime.
After you have called eth_register() in your driver's register function, add
a call to miiphy_register() like so:
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_register(dev->name, mii_read, mii_write);
#endif
And then define the mii_read and mii_write functions if you haven't already.
Their syntax is straightforward:
int mii_read(char *devname, uchar addr, uchar reg, ushort *val);
int mii_write(char *devname, uchar addr, uchar reg, ushort val);
The read function should read the register 'reg' from the phy at address 'addr'
and store the result in the pointer 'val'. The implementation for the write
function should logically follow.

136
common/package/boot/uboot-ipq40xx/src/doc/README.ebony Normal file
View file

@ -0,0 +1,136 @@
AMCC Ebony Board
Last Update: September 12, 2002
=======================================================================
This file contains some handy info regarding U-Boot and the AMCC
Ebony evaluation 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 probe
=====================
The i2c utilities have been tested on both Rev B. and Rev C. and
look good. The CONFIG_SYS_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
'i2c probe' should look like this (assuming you are only using a single
SO-DIMM:
=> i2c probe
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 'i2c mm' command. Here are the values I currently
use:
=> i2c md 50 0 10
0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................
=> i2c md 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 'i2c probe', then
use 'i2c md' 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 'i2c mm' 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.
=> i2c md 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>

112
common/package/boot/uboot-ipq40xx/src/doc/README.enetaddr Normal file
View file

@ -0,0 +1,112 @@
---------------------------------
Ethernet Address (MAC) Handling
---------------------------------
There are a variety of places in U-Boot where the MAC address is used, parsed,
and stored. This document covers proper usage of each location and the moving
of data between them.
-----------
Locations
-----------
Here are the places where MAC addresses might be stored:
- board-specific location (eeprom, dedicated flash, ...)
Note: only used when mandatory due to hardware design etc...
- environment ("ethaddr", "eth1addr", ...) (see CONFIG_ETHADDR)
Note: this is the preferred way to permanently store MAC addresses
- ethernet data (struct eth_device -> enetaddr)
Note: these are temporary copies of the MAC address which exist only
after the respective init steps have run and only to make usage
in other places easier (to avoid constant env lookup/parsing)
- struct bd_info and/or device tree
Note: these are temporary copies of the MAC address only for the
purpose of passing this information to an OS kernel we are about
to boot
Correct flow of setting up the MAC address (summarized):
1. Read from hardware in initialize() function
2. Read from environment in net/eth.c after initialize()
3. Give priority to the value in the environment if a conflict
4. Program the address into hardware if the following conditions are met:
a) The relevant driver has a 'write_addr' function
b) The user hasn't set an 'ethmacskip' environment variable
c) The address is valid (unicast, not all-zeros)
Previous behavior had the MAC address always being programmed into hardware
in the device's init() function.
-------
Usage
-------
If the hardware design mandates that the MAC address is stored in some special
place (like EEPROM etc...), then the board specific init code (such as the
board-specific misc_init_r() function) is responsible for locating the MAC
address(es) and initializing the respective environment variable(s) from it.
Note that this shall be done if, and only if, the environment does not already
contain these environment variables, i.e. existing variable definitions must
not be overwritten.
During runtime, the ethernet layer will use the environment variables to sync
the MAC addresses to the ethernet structures. All ethernet driver code should
then only use the enetaddr member of the eth_device structure. This is done
on every network command, so the ethernet copies will stay in sync.
Any other code that wishes to access the MAC address should query the
environment directly. The helper functions documented below should make
working with this storage much smoother.
---------
Helpers
---------
To assist in the management of these layers, a few helper functions exist. You
should use these rather than attempt to do any kind of parsing/manipulation
yourself as many common errors have arisen in the past.
* void eth_parse_enetaddr(const char *addr, uchar *enetaddr);
Convert a string representation of a MAC address to the binary version.
char *addr = "00:11:22:33:44:55";
uchar enetaddr[6];
eth_parse_enetaddr(addr, enetaddr);
/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */
* int eth_getenv_enetaddr(char *name, uchar *enetaddr);
Look up an environment variable and convert the stored address. If the address
is valid, then the function returns 1. Otherwise, the function returns 0. In
all cases, the enetaddr memory is initialized. If the env var is not found,
then it is set to all zeros. The common function is_valid_ether_addr() is used
to determine address validity.
uchar enetaddr[6];
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
/* "ethaddr" is not set in the environment */
... try and setup "ethaddr" in the env ...
}
/* enetaddr is now set to the value stored in the ethaddr env var */
* int eth_setenv_enetaddr(char *name, const uchar *enetaddr);
Store the MAC address into the named environment variable. The return value is
the same as the setenv() function.
uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
eth_setenv_enetaddr("ethaddr", enetaddr);
/* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */
* the %pM format modifier
The %pM format modifier can be used with any standard printf function to format
the binary 6 byte array representation of a MAC address.
uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
printf("The MAC is %pM\n", enetaddr);
char buf[20];
sprintf(buf, "%pM", enetaddr);
/* the buf variable is now set to "00:11:22:33:44:55" */

54
common/package/boot/uboot-ipq40xx/src/doc/README.evb64260 Normal file
View file

@ -0,0 +1,54 @@
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
common/package/boot/uboot-ipq40xx/src/doc/README.fads Normal file
View file

@ -0,0 +1,89 @@
/*
* (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.

184
common/package/boot/uboot-ipq40xx/src/doc/README.fdt-control Normal file
View file

@ -0,0 +1,184 @@
#
# Copyright (c) 2011 The Chromium OS Authors.
#
# 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 Foundatio; 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
#
Device Tree Control in U-Boot
=============================
This feature provides for run-time configuration of U-Boot via a flat
device tree (fdt). U-Boot configuration has traditionally been done
using CONFIG options in the board config file. This feature aims to
make it possible for a single U-Boot binary to support multiple boards,
with the exact configuration of each board controlled by a flat device
tree (fdt). This is the approach recently taken by the ARM Linux kernel
and has been used by PowerPC for some time.
The fdt is a convenient vehicle for implementing run-time configuration
for three reasons. Firstly it is easy to use, being a simple text file.
It is extensible since it consists of nodes and properties in a nice
hierarchical format.
Finally, there is already excellent infrastructure for the fdt: a
compiler checks the text file and converts it to a compact binary
format, and a library is already available in U-Boot (libfdt) for
handling this format.
The dts directory contains a Makefile for building the device tree blob
and embedding it in your U-Boot image. This is useful since it allows
U-Boot to configure itself according to what it finds there. If you have
a number of similar boards with different peripherals, you can describe
the features of each board in the device tree file, and have a single
generic source base.
To enable this feature, add CONFIG_OF_CONTROL to your board config file.
What is a Flat Device Tree?
---------------------------
An fdt can be specified in source format as a text file. To read about
the fdt syntax, take a look at the specification here:
https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
You also might find this section of the Linux kernel documentation
useful: (access this in the Linux kernel source code)
Documentation/devicetree/booting-without-of.txt
There is also a mailing list:
http://lists.ozlabs.org/listinfo/devicetree-discuss
In case you are wondering, OF stands for Open Firmware.
Tools
-----
To use this feature you will need to get the device tree compiler here:
git://jdl.com/software/dtc.git
For example:
$ git clone git://jdl.com/software/dtc.git
$ cd dtc
$ make
$ sudo make install
Then run the compiler (your version will vary):
$ dtc -v
Version: DTC 1.2.0-g2cb4b51f
$ make tests
$ cd tests
$ ./run_tests.sh
********** TEST SUMMARY
* Total testcases: 1371
* PASS: 1371
* FAIL: 0
* Bad configuration: 0
* Strange test result: 0
You will also find a useful ftdump utility for decoding a binary file.
Where do I get an fdt file for my board?
----------------------------------------
You may find that the Linux kernel has a suitable file. Look in the
kernel source in arch/<arch>/boot/dts.
If not you might find other boards with suitable files that you can
modify to your needs. Look in the board directories for files with a
.dts extension.
Failing that, you could write one from scratch yourself!
Configuration
-------------
Use:
#define CONFIG_DEFAULT_DEVICE_TREE "<name>"
to set the filename of the device tree source. Then put your device tree
file into
board/<vendor>/dts/<name>.dts
This should include your CPU or SOC's device tree file, placed in
arch/<arch>/dts, and then make any adjustments required. The name of this
is CONFIG_ARCH_DEVICE_TREE.dts.
If CONFIG_OF_EMBED is defined, then it will be picked up and built into
the U-Boot image (including u-boot.bin).
If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
a u-boot.dtb file alongside u-boot.bin. A common approach is then to
join the two:
cat u-boot.bin u-boot.dtb >image.bin
and then flash image.bin onto your board.
You cannot use both of these options at the same time.
If you wish to put the fdt at a different address in memory, you can
define the "fdtcontroladdr" environment variable. This is the hex
address of the fdt binary blob, and will override either of the options.
Be aware that this environment variable is checked prior to relocation,
when only the compiled-in environment is available. Therefore it is not
possible to define this variable in the saved SPI/NAND flash
environment, for example (it will be ignored).
To use this, put something like this in your board header file:
#define CONFIG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0"
Limitations
-----------
U-Boot is designed to build with a single architecture type and CPU
type. So for example it is not possible to build a single ARM binary
which runs on your AT91 and OMAP boards, relying on an fdt to configure
the various features. This is because you must select one of
the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build
time. Similarly you cannot build for multiple cpu types or
architectures.
That said the complexity reduction by using fdt to support variants of
boards which use the same SOC / CPU can be substantial.
It is important to understand that the fdt only selects options
available in the platform / drivers. It cannot add new drivers (yet). So
you must still have the CONFIG option to enable the driver. For example,
you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver,
but can use the fdt to specific the UART clock, peripheral address, etc.
In very broad terms, the CONFIG options in general control *what* driver
files are pulled in, and the fdt controls *how* those files work.
--
Simon Glass <sjg@chromium.org>
1-Sep-11

374
common/package/boot/uboot-ipq40xx/src/doc/README.fsl-ddr Normal file
View file

@ -0,0 +1,374 @@
Table of interleaving modes supported in cpu/8xxx/ddr/
======================================================
+-------------+---------------------------------------------------------+
| | Rank Interleaving |
| +--------+-----------+-----------+------------+-----------+
|Memory | | | | 2x2 | 4x1 |
|Controller | None | 2x1 lower | 2x1 upper | {CS0+CS1}, | {CS0+CS1+ |
|Interleaving | | {CS0+CS1} | {CS2+CS3} | {CS2+CS3} | CS2+CS3} |
+-------------+--------+-----------+-----------+------------+-----------+
|None | Yes | Yes | Yes | Yes | Yes |
+-------------+--------+-----------+-----------+------------+-----------+
|Cacheline | Yes | Yes | No | No, Only(*)| Yes |
| |CS0 Only| | | {CS0+CS1} | |
+-------------+--------+-----------+-----------+------------+-----------+
|Page | Yes | Yes | No | No, Only(*)| Yes |
| |CS0 Only| | | {CS0+CS1} | |
+-------------+--------+-----------+-----------+------------+-----------+
|Bank | Yes | Yes | No | No, Only(*)| Yes |
| |CS0 Only| | | {CS0+CS1} | |
+-------------+--------+-----------+-----------+------------+-----------+
|Superbank | No | Yes | No | No, Only(*)| Yes |
| | | | | {CS0+CS1} | |
+-------------+--------+-----------+-----------+------------+-----------+
(*) Although the hardware can be configured with memory controller
interleaving using "2x2" rank interleaving, it only interleaves {CS0+CS1}
from each controller. {CS2+CS3} on each controller are only rank
interleaved on that controller.
For memory controller interleaving, identical DIMMs are suggested. Software
doesn't check the size or organization of interleaved DIMMs.
The ways to configure the ddr interleaving mode
==============================================
1. In board header file(e.g.MPC8572DS.h), add default interleaving setting
under "CONFIG_EXTRA_ENV_SETTINGS", like:
#define CONFIG_EXTRA_ENV_SETTINGS \
"hwconfig=fsl_ddr:ctlr_intlv=bank" \
......
2. Run u-boot "setenv" command to configure the memory interleaving mode.
Either numerical or string value is accepted.
# disable memory controller interleaving
setenv hwconfig "fsl_ddr:ctlr_intlv=null"
# cacheline interleaving
setenv hwconfig "fsl_ddr:ctlr_intlv=cacheline"
# page interleaving
setenv hwconfig "fsl_ddr:ctlr_intlv=page"
# bank interleaving
setenv hwconfig "fsl_ddr:ctlr_intlv=bank"
# superbank
setenv hwconfig "fsl_ddr:ctlr_intlv=superbank"
# disable bank (chip-select) interleaving
setenv hwconfig "fsl_ddr:bank_intlv=null"
# bank(chip-select) interleaving cs0+cs1
setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1"
# bank(chip-select) interleaving cs2+cs3
setenv hwconfig "fsl_ddr:bank_intlv=cs2_cs3"
# bank(chip-select) interleaving (cs0+cs1) and (cs2+cs3) (2x2)
setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_and_cs2_cs3"
# bank(chip-select) interleaving (cs0+cs1+cs2+cs3) (4x1)
setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_cs2_cs3"
Memory controller address hashing
==================================
If the DDR controller supports address hashing, it can be enabled by hwconfig.
Syntax is:
hwconfig=fsl_ddr:addr_hash=true
Memory controller ECC on/off
============================
If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC,
ECC can be turned on/off by hwconfig.
Syntax is
hwconfig=fsl_ddr:ecc=off
Memory testing options for mpc85xx
==================================
1. Memory test can be done once U-boot prompt comes up using mtest, or
2. Memory test can be done with Power-On-Self-Test function, activated at
compile time.
In order to enable the POST memory test, CONFIG_POST needs to be
defined in board configuraiton header file. By default, POST memory test
performs a fast test. A slow test can be enabled by changing the flag at
compiling time. To test memory bigger than 2GB, 36BIT support is needed.
Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB
window to physical address so that all physical memory can be tested.
Combination of hwconfig
=======================
Hwconfig can be combined with multiple parameters, for example, on a supported
platform
hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
Table for dynamic ODT for DDR3
==============================
For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT may
be needed, depending on the configuration. The numbers in the following tables are
in Ohms.
* denotes dynamic ODT
Two slots system
+-----------------------+----------+---------------+-----------------------------+-----------------------------+
| Configuration | |DRAM controller| Slot 1 | Slot 2 |
+-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
+ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 75 | 120 | off | off | off | off | off | 30 | 30 |
| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 75 | off | off | 30 | 30 | 120 | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 75 | 120 | off | off | off | 20 | 20 | | |
| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 75 | off | off | 20 | 20 | 120 *| off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 75 | 120 *| off | | | off | off | 20 | 20 |
|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 75 | 20 | 20 | | | 120 | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 75 | 120 *| off | | | 30 | 30 | | |
|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 75 | 30 | 30 | | | 120 *| off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Dual Rank | Empty | Slot 1 | off | 75 | 40 | off | off | off | | | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 40 | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
|Single Rank| Empty | Slot 1 | off | 75 | 40 | off | | | | | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Empty |Single Rank| Slot 2 | off | 75 | | | | | 40 | off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
Single slot system
+-------------+------------+---------------+-----------------------------+-----------------------------+
| | |DRAM controller| Rank 1 | Rank 2 | Rank 3 | Rank 4 |
|Configuration| Write/Read |-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Write | Read | Write | Read | Write | Read | Write | Read | Write | Read |
+-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | R1 | off | 75 | 120 *| off | off | off | 20 | 20 | off | off |
| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | R2 | off | 75 | off | 20 | 120 | off | 20 | 20 | off | off |
| Quad Rank |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | R3 | off | 75 | 20 | 20 | off | off | 120 *| off | off | off |
| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | R4 | off | 75 | 20 | 20 | off | off | off | 20 | 120 | off |
+-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | R1 | off | 75 | 40 | off | off | off |
| Dual Rank |------------+-------+-------+-------+------+-------+------+
| | R2 | off | 75 | 40 | off | off | off |
+-------------+------------+-------+-------+-------+------+-------+------+
| Single Rank | R1 | off | 75 | 40 | off |
+-------------+------------+-------+-------+-------+------+
Reference http://www.xrosstalkmag.com/mag_issues/xrosstalk_oct08_final.pdf
http://download.micron.com/pdf/technotes/ddr3/tn4108_ddr3_design_guide.pdf
Table for ODT for DDR2
======================
Two slots system
+-----------------------+----------+---------------+-----------------------------+-----------------------------+
| Configuration | |DRAM controller| Slot 1 | Slot 2 |
+-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
+ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | off | off |
| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | | |
| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | off | off |
|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | | |
|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Dual Rank | Empty | Slot 1 | off | 75 | 150 | off | off | off | | | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 150 | off | off | off |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
|Single Rank| Empty | Slot 1 | off | 75 | 150 | off | | | | | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
| Empty |Single Rank| Slot 2 | off | 75 | | | | | 150 | off | | |
+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
Single slot system
+-------------+------------+---------------+-----------------------------+
| | |DRAM controller| Rank 1 | Rank 2 |
|Configuration| Write/Read |-------+-------+-------+------+-------+------+
| | | Write | Read | Write | Read | Write | Read |
+-------------+------------+-------+-------+-------+------+-------+------+
| | R1 | off | 75 | 150 | off | off | off |
| Dual Rank |------------+-------+-------+-------+------+-------+------+
| | R2 | off | 75 | 150 | off | off | off |
+-------------+------------+-------+-------+-------+------+-------+------+
| Single Rank | R1 | off | 75 | 150 | off |
+-------------+------------+-------+-------+-------+------+
Reference http://www.samsung.com/global/business/semiconductor/products/dram/downloads/applicationnote/ddr2_odt_control_200603.pdf
Interactive DDR debugging
===========================
For DDR parameter tuning up and debugging, the interactive DDR debugging can
be activated by saving an environment variable "ddr_interactive". The value
doesn't matter. Once activated, U-boot prompts "FSL DDR>" before enabling DDR
controller. The available commands can be seen by typing "help".
The example flow of using interactive debugging is
type command "compute" to calculate the parameters from the default
type command "print" with arguments to show SPD, options, registers
type command "edit" with arguments to change any if desired
type command "go" to continue calculation and enable DDR controller
type command "reset" to reset the board
type command "recompute" to reload SPD and start over
Note, check "next_step" to show the flow. For example, after edit opts, the
next_step is STEP_ASSIGN_ADDRESSES. After editing registers, the next_step is
STEP_PROGRAM_REGS. Upon issuing command "go", DDR controller will be enabled
with current setting without further calculation.
The detail syntax for each commands are
print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
c<n> - the controller number, eg. c0, c1
d<n> - the DIMM number, eg. d0, d1
spd - print SPD data
dimmparms - DIMM parameters, calculated from SPD
commonparms - lowest common parameters for all DIMMs
opts - options
addresses - address assignment (not implemented yet)
regs - controller registers
edit <c#> <d#> <spd|dimmparms|commonparms|opts|addresses|regs> <element> <value>
c<n> - the controller number, eg. c0, c1
d<n> - the DIMM number, eg. d0, d1
spd - print SPD data
dimmparms - DIMM parameters, calculated from SPD
commonparms - lowest common parameters for all DIMMs
opts - options
addresses - address assignment (not implemented yet)
regs - controller registers
<element> - name of the modified element
byte number if the object is SPD
<value> - decimal or heximal (prefixed with 0x) numbers
reset
no arguement - reset the board
recompute
no argument - reload SPD and start over
compute
no argument - recompute from current next_step
next_step
no argument - show current next_step
help
no argument - print a list of all commands
go
no argument - program memory controller(s) and continue with U-boot
Examples of debugging flow
FSL DDR>compute
Detected UDIMM UG51U6400N8SU-ACF
SL DDR>print
print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
FSL DDR>print dimmparms
DIMM parameters: Controller=0 DIMM=0
DIMM organization parameters:
module part name = UG51U6400N8SU-ACF
rank_density = 2147483648 bytes (2048 megabytes)
capacity = 4294967296 bytes (4096 megabytes)
burst_lengths_bitmask = 0C
base_addresss = 0 (00000000 00000000)
n_ranks = 2
data_width = 64
primary_sdram_width = 64
ec_sdram_width = 0
registered_dimm = 0
n_row_addr = 15
n_col_addr = 10
edc_config = 0
n_banks_per_sdram_device = 8
tCKmin_X_ps = 1500
tCKmin_X_minus_1_ps = 0
tCKmin_X_minus_2_ps = 0
tCKmax_ps = 0
caslat_X = 960
tAA_ps = 13125
caslat_X_minus_1 = 0
caslat_X_minus_2 = 0
caslat_lowest_derated = 0
tRCD_ps = 13125
tRP_ps = 13125
tRAS_ps = 36000
tWR_ps = 15000
tWTR_ps = 7500
tRFC_ps = 160000
tRRD_ps = 6000
tRC_ps = 49125
refresh_rate_ps = 7800000
tIS_ps = 0
tIH_ps = 0
tDS_ps = 0
tDH_ps = 0
tRTP_ps = 7500
tDQSQ_max_ps = 0
tQHS_ps = 0
FSL DDR>edit c0 opts ECC_mode 0
FSL DDR>edit c0 regs cs0_bnds 0x000000FF
FSL DDR>go
2 GiB left unmapped
4 GiB (DDR3, 64-bit, CL=9, ECC off)
DDR Chip-Select Interleaving Mode: CS0+CS1
Testing 0x00000000 - 0x7fffffff
Testing 0x80000000 - 0xffffffff
Remap DDR 2 GiB left unmapped
POST memory PASSED
Flash: 128 MiB
L2: 128 KB enabled
Corenet Platform Cache: 1024 KB enabled
SERDES: timeout resetting bank 3
SRIO1: disabled
SRIO2: disabled
MMC: FSL_ESDHC: 0
EEPROM: Invalid ID (ff ff ff ff)
PCIe1: disabled
PCIe2: Root Complex, x1, regs @ 0xfe201000
01:00.0 - 8086:10d3 - Network controller
PCIe2: Bus 00 - 01
PCIe3: disabled
In: serial
Out: serial
Err: serial
Net: Initializing Fman
Fman1: Uploading microcode version 101.8.0
e1000: 00:1b:21:81:d2:e0
FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, e1000#0 [PRIME]
Warning: e1000#0 MAC addresses don't match:
Address in SROM is 00:1b:21:81:d2:e0
Address in environment is 00:e0:0c:00:ea:05
Hit any key to stop autoboot: 0
=>

46
common/package/boot/uboot-ipq40xx/src/doc/README.fsl-hwconfig Normal file
View file

@ -0,0 +1,46 @@
Freescale-specific 'hwconfig' options.
This file documents Freescale-specific key:value pairs for the 'hwconfig'
option. See README.hwconfig for general information about 'hwconfig'.
audclk
Specific to the P1022DS reference board.
This option specifies which of the two oscillator frequencies should be
routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to
route either a 11.2896MHz or a 12.288MHz clock. The default is
12.288MHz. This option has two effects. First, the MUX on the board
will be programmed accordingly. Second, the clock-frequency property
in the codec node in the device tree will be updated to the correct
value.
'audclk:11'
Select the 11.2896MHz clock
'audclk:12'
Select the 12.288MHz clock
usb
Specific to boards have USB controller
This option specifies the following for a USB controller:
- which controller mode to use
- which USB PHY to use
This is used by generic USB device-tree fixup function to update
modified values of phy type and controller mode.
Also used for configuring multiple USB controllers such that
'usbN' (where N is 1, 2, etc. refers to controller no.)
'phy_type'
Select USB phy type: 'utmi' OR 'ulpi'
'dr_mode'
Select USB controller mode: 'host', 'peripheral' OR 'otg'
Examples:
usb1:dr_mode=host;usb2:dr_mode=peripheral'
usb1:dr_mode=host,phy_type=utmi;usb2:dr_mode=host'

63
common/package/boot/uboot-ipq40xx/src/doc/README.generic_usb_ohci Normal file
View file

@ -0,0 +1,63 @@
Notes on the the generic USB-OHCI driver
========================================
This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of
various existing OHCI drivers that were basically identical beside
cpu/board dependant initalization. This initalization has been moved
into cpu/board directories and are called via the hooks below.
Configuration options
----------------------
CONFIG_USB_OHCI_NEW: enable the new OHCI driver
CONFIG_SYS_USB_OHCI_BOARD_INIT: call the board dependant hooks:
- extern int usb_board_init(void);
- extern int usb_board_stop(void);
- extern int usb_cpu_init_fail(void);
CONFIG_SYS_USB_OHCI_CPU_INIT: call the cpu dependant hooks:
- extern int usb_cpu_init(void);
- extern int usb_cpu_stop(void);
- extern int usb_cpu_init_fail(void);
CONFIG_SYS_USB_OHCI_REGS_BASE: defines the base address of the OHCI
registers
CONFIG_SYS_USB_OHCI_SLOT_NAME: slot name
CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS: maximal number of ports of the
root hub.
Endianness issues
------------------
The USB bus operates in little endian, but unfortunately there are
OHCI controllers that operate in big endian such as ppc4xx and
mpc5xxx. For these the config option
CONFIG_SYS_OHCI_BE_CONTROLLER
needs to be defined.
PCI Controllers
----------------
You'll need to define
CONFIG_PCI_OHCI
If you have several USB PCI controllers, define
CONFIG_PCI_OHCI_DEVNO: number of the OHCI device in PCI list
If undefined, the first instance found in PCI space will be used.
PCI Controllers need to do byte swapping on register accesses, so they
should to define:
CONFIG_SYS_OHCI_SWAP_REG_ACCESS

92
common/package/boot/uboot-ipq40xx/src/doc/README.hawkboard Normal file
View file

@ -0,0 +1,92 @@
Summary
=======
The README is for the boot procedure used for TI's OMAP-L138 based
hawkboard. The hawkboard comes with a 128MiB Nand flash and a 128MiB
DDR SDRAM along with a host of other controllers.
The hawkboard is booted in three stages. The initial bootloader which
executes upon reset is the Rom Boot Loader(RBL) which sits in the
internal ROM of the omap. The RBL initialises the memory and the nand
controller, and copies the image stored at a predefined location(block
1) of the nand flash. The image loaded by the RBL to the memory is the
AIS signed spl image. This, in turns copies the u-boot binary from the
nand flash to the memory and jumps to the u-boot entry point.
AIS is an image format defined by TI for the images that are to be
loaded to memory by the RBL. The image is divided into a series of
sections and the image's entry point is specified. Each section comes
with meta data like the target address the section is to be copied to
and the size of the section, which is used by the RBL to load the
image. At the end of the image the RBL jumps to the image entry
point.
The secondary stage bootloader(spl) which is loaded by the RBL then
loads the u-boot from a predefined location in the nand to the memory
and jumps to the u-boot entry point.
The reason a secondary stage bootloader is used is because the ECC
layout expected by the RBL is not the same as that used by
u-boot/linux. This also implies that for flashing the spl image,we
need to use the u-boot which uses the ECC layout expected by the
RBL[1]. Booting u-boot over UART(UART boot) is explained here[2].
Compilation
===========
Three images might be needed
* spl - This is the secondary bootloader which boots the u-boot
binary.
* u-boot binary - This is the image flashed to the nand and copied to
the memory by the spl.
Both the images get compiled with hawkboard_config, with the TOPDIR
containing the u-boot images, and the spl image under the spl
directory.
The spl image needs to be processed with the AISGen tool for
generating the AIS signed image to be flashed. Steps for generating
the AIS image are explained here[3].
* u-boot for uart boot - This is same as the u-boot binary generated
above, with the sole difference of the CONFIG_SYS_TEXT_BASE being
0xc1080000, as expected by the RBL.
hawkboard_uart_config
Flashing the images to Nand
===========================
The spl AIS image needs to be flashed to the block 1 of the Nand
flash, as that is the location the RBL expects the image[4]. For
flashing the spl, boot over the u-boot specified in [1], and flash the
image
=> tftpboot 0xc0700000 <nand_spl_ais.bin>
=> nand erase 0x20000 0x20000
=> nand write.e 0xc0700000 0x20000 <nand_spl_size>
The u-boot binary is flashed at location 0xe0000(block 6) of the nand
flash. The spl loader expects the u-boot at this location. For
flashing the u-boot binary
=> tftpboot 0xc0700000 u-boot.bin
=> nand erase 0xe0000 0x40000
=> nand write.e 0xc0700000 0xe0000 <u-boot-size>
Links
=====
[1]
http://code.google.com/p/hawkboard/downloads/detail?name=u-boot_uart_ais_v1.bin
[2]
http://elinux.org/Hawkboard#Booting_u-boot_over_UART
[3]
http://elinux.org/Hawkboard#Signing_u-boot_for_UART_boot
[4]
http://processors.wiki.ti.com/index.php/RBL_UBL_and_host_program#RBL_booting_from_NAND_and_ECC.2FBad_blocks

50
common/package/boot/uboot-ipq40xx/src/doc/README.hwconfig Normal file
View file

@ -0,0 +1,50 @@
To enable this feature just define CONFIG_HWCONFIG in your board
config file.
This implements a simple hwconfig infrastructure: an
interface for software knobs to control hardware.
This a is very simple implementation, i.e. it is implemented
via the `hwconfig' environment variable. Later we could write
some "hwconfig <enable|disable|list>" commands, ncurses
interface for Award BIOS-like interface, and frame-buffer
interface for AMI GUI[1] BIOS-like interface with mouse
support[2].
Current implementation details/limitations:
1. Doesn't support options dependencies and mutual exclusion.
We can implement this by integrating apt-get[3] into Das
U-Boot. But I haven't bothered yet.
2. Since we don't implement a hwconfig command, i.e. we're working
with the environement directly, there is no way to tell that
toggling a particular option will need a reboot to take
effect. So, for now it's advised to always reboot the
target after modifying the hwconfig variable.
3. We support hwconfig options with arguments. For example,
set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi"
This selects three hwconfig options:
1. dr_usb - enable Dual-Role USB controller;
2. dr_usb_mode:peripheral - USB in Function mode;
3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs.
The purpose of this simple implementation is to refine the
internal API and then we can continue improving the user
experience by adding more mature interfaces, like a hwconfig
command with bells and whistles. Or not adding, if we feel
that the current interface fits people's needs.
[1] http://en.wikipedia.org/wiki/American_Megatrends
[2] Regarding ncurses and GUI with mouse support -- I'm just
kidding.
[3] The comment regarding apt-get is also a joke, meaning that
dependency tracking could be non-trivial. For example, for
enabling HW feature X we may need to disable Y, and turn Z
into reduced mode (like RMII-only interface for ethernet,
no MII).
It's quite trivial to implement simple cases though.

10
common/package/boot/uboot-ipq40xx/src/doc/README.idma2intr Normal file
View file

@ -0,0 +1,10 @@
(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
Attached is an IDMA example code for MPC8260/PPCBoot. I had tried to
search around and could not find any for implementing IDMA, so
implemented one. Its not coded in the best way, but works.
Also, I was able to test the IDMA specific code under Linux also
(with modifications). My requirement was to implement it for
CompactFlash implemented in memory mode, and it works for it under
PPCBoot and Linux.

29
common/package/boot/uboot-ipq40xx/src/doc/README.imx31 Normal file
View file

@ -0,0 +1,29 @@
U-Boot for Freescale i.MX31
This file contains information for the port of U-Boot to the Freescale
i.MX31 SoC.
1. CONFIGURATION OPTIONS/SETTINGS
---------------------------------
1.1 Configuration of MC13783 SPI bus
------------------------------------
The power management companion chip MC13783 is connected to the
i.MX31 via an SPI bus. Use the following configuration options
to setup the bus and chip select used for a particular board.
CONFIG_MC13783_SPI_BUS -- defines the SPI bus the MC13783 is connected to.
Note that 0 is CSPI1, 1 is CSPI2 and 2 is CSPI3.
CONFIG_MC13783_SPI_CS -- define the chip select the MC13783 s connected to.
1.2 Timer precision
-------------------
CONFIG_MX31_TIMER_HIGH_PRECISION
Enable higher precision timer. The low-precision timer
(default) provides approximately 4% error, whereas the
high-precision timer is about 0.4% accurate. The extra
accuracy is achieved at the cost of higher computational
overhead, which, in places where time is measured, should
not be critical, so, it should be safe to enable this
option.

17
common/package/boot/uboot-ipq40xx/src/doc/README.imx5 Normal file
View file

@ -0,0 +1,17 @@
U-Boot for Freescale i.MX5x
This file contains information for the port of U-Boot to the Freescale
i.MX5x SoCs.
1. CONFIGURATION OPTIONS/SETTINGS
---------------------------------
1.1 CONFIG_MX51_PLL_ERRATA: Workaround for i.MX51 PLL errata.
This option should be enabled by all boards using the i.MX51 silicon
version up until (including) 3.0 running at 800MHz.
The PLL's in the i.MX51 processor can go out of lock due to a metastable
condition in an analog flip-flop when used at high frequencies.
This workaround implements an undocumented feature in the PLL (dither
mode), which causes the effect of this failure to be much lower (in terms
of frequency deviation), avoiding system failure, or at least decreasing
the likelihood of system failure.

197
common/package/boot/uboot-ipq40xx/src/doc/README.imximage Normal file
View file

@ -0,0 +1,197 @@
---------------------------------------------
Imximage Boot Image generation using mkimage
---------------------------------------------
This document describes how to set up a U-Boot image that can be booted
by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
mode.
These processors can boot directly from NAND, SPI flash and SD card flash
using its internal boot ROM support. MX6 processors additionally support
boot from NOR flash and SATA disks. All processors can boot from an internal
UART, if booting from device media fails.
Booting from NOR flash does not require to use this image type.
For more details refer Chapter 2 - System Boot and section 2.14
(flash header description) of the processor's manual.
This implementation does not use at the moment the secure boot feature
of the processor. The image is generated disabling all security fields.
Command syntax:
--------------
./tools/mkimage -l <mx u-boot_file>
to list the imx image file details
./tools/mkimage -T imximage \
-n <board specific configuration file> \
-e <execution address> -d <u-boot binary> <output image file>
For example, for the mx51evk board:
./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \
-T imximage -e 0x97800000 \
-d u-boot.bin u-boot.imx
You can generate directly the image when you compile u-boot with:
$ make u-boot.imx
The output image can be flashed on the board SPI flash or on a SD card.
In both cases, you have to copy the image at the offset required for the
chosen media devices (0x400 for both SPI flash or SD card).
Please check Freescale documentation for further details.
Board specific configuration file specifications:
-------------------------------------------------
1. This file must present in the $(BOARDDIR) and the name should be
imximage.cfg (since this is used in Makefile).
2. This file can have empty lines and lines starting with "#" as first
character to put comments.
3. This file can have configuration command lines as mentioned below,
any other information in this file is treated as invalid.
Configuration command line syntax:
---------------------------------
1. Each command line is must have two strings, first one command or address
and second one data string
2. Following are the valid command strings and associated data strings:-
Command string data string
-------------- -----------
IMXIMAGE_VERSION 1/2
1 is for mx25/mx35/mx51 compatible,
2 is for mx53/mx6 compatible,
others is invalid and error is generated.
This command need appear the fist before
other valid commands in configuration file.
BOOT_FROM nand/spi/sd/onenand/nor/sata
Example:
BOOT_FROM spi
DATA type address value
type: word=4, halfword=2, byte=1
address: physycal register address
value: value to be set in register
All values are in in hexadecimal.
Example (write to IOMUXC):
DATA 4 0x73FA88a0 0x200
The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1
and 121 register programming commands for IMXIMAGE_VERSION 2.
An error is generated if more commands are found in the configuration file.
3. All commands are optional to program.
Setup a SD Card for booting
--------------------------------
The following example prepare a SD card with u-boot and a FAT partition
to be used to stored the kernel to be booted.
I will set the SD in the most compatible mode, setting it with
255 heads and 63 sectors, as suggested from several documentation and
howto on line (I took as reference the preparation of a SD Card for the
Beagleboard, running u-boot as bootloader).
You should start clearing the partitions table on the SD card. Because
the u-boot image must be stored at the offset 0x400, it must be assured
that there is no partition at that address. A new SD card is already
formatted with FAT filesystem and the partition starts from the first
cylinder, so we need to change it.
You can do all steps with fdisk. If the device for the SD card is
/dev/mmcblk0, the following commands make the job:
1. Start the fdisk utility (as superuser)
fdisk /dev/mmcblk0
2. Clear the actual partition
Command (m for help): o
3. Print card info:
Command (m for help): p
Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes
In my case, I have a 2 GB card. I need the size to set later the correct value
for the cylinders.
4. Go to expert mode:
Command (m for help): x
5. Set card geometry
Expert command (m for help): h
Number of heads (1-256, default 4): 255
Expert command (m for help): s
Number of sectors (1-63, default 16): 63
Warning: setting sector offset for DOS compatiblity
We have set 255 heads, 63 sector. We have to set the cylinder.
The value to be set can be calculated with:
cilynder = <total size> / <heads> / <sectors> / <blocksize>
in this example,
1981284352 / 255 / 63 / 512 = 239.x = 239
Expert command (m for help): c
Number of cylinders (1-1048576, default 60032): 239
6. Leave the expert mode
Expert command (m for help): r
7. Set up a partition
Now set a partition table to store the kernel or whatever you want. Of course,
you can set additional partitions to store rootfs, data, etc.
In my example I want to set a single partition. I must take care
to not overwrite the space where I will put u-boot.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-239, default 1): 3
Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M
Command (m for help): p
Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes
255 heads, 63 sectors/track, 239 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb712a870
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 3 16 112455 83 Linux
I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
there.
8. Write the partition table and exit.
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
9. Copy u-boot.imx on the SD card
I use dd:
dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
This command copies the u-boot image at the address 0x400, as required
by the processor.
Now remove your card from the PC and go to the target. If evrything went right,
the u-boot prompt should come after power on.
------------------------------------------------
Author: Stefano babic <sbabic@denx.de>

106
common/package/boot/uboot-ipq40xx/src/doc/README.iomux Normal file
View file

@ -0,0 +1,106 @@
/*
* (C) Copyright 2008
* Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de>
*
* 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 multiplexing
===========================
HOW CONSOLE MULTIPLEXING WORKS
------------------------------
This functionality is controlled with CONFIG_CONSOLE_MUX in the board
configuration file.
Two new files, common/iomux.c and include/iomux.h, contain the heart
(iomux_doenv()) of the environment setting implementation.
iomux_doenv() is called in common/cmd_nvedit.c to handle setenv and in
common/console.c in console_init_r() during bootup to initialize
stdio_devices[].
A user can use a comma-separated list of devices to set stdin, stdout
and stderr. For example: "setenv stdin serial,nc". NOTE: No spaces
are allowed around the comma(s)!
The length of the list is limited by malloc(), since the array used
is allocated and freed dynamically.
It should be possible to specify any device which console_assign()
finds acceptable, but the code has only been tested with serial and
nc.
iomux_doenv() prevents multiple use of the same device, e.g. "setenv
stdin nc,nc,serial" will discard the second nc. iomux_doenv() is
not able to modify the environment, however, so that "pri stdin" still
shows "nc,nc,serial".
The major change in common/console.c was to modify fgetc() to call
the iomux_tstc() routine in a for-loop. iomux_tstc() in turn calls
the tstc() routine for every registered device, but exits immediately
when one of them returns true. fgetc() then calls iomux_getc(),
which calls the corresponding getc() routine. fgetc() hangs in
the for-loop until iomux_tstc() returns true and the input can be
retrieved.
Thus, a user can type into any device registered for stdin. No effort
has been made to demulitplex simultaneous input from multiple stdin
devices.
fputc() and fputs() have been modified to call iomux_putc() and
iomux_puts() respectively, which call the corresponding output
routines for every registered device.
Thus, a user can see the ouput for any device registered for stdout
or stderr on all devices registered for stdout or stderr. As an
example, if stdin=serial,nc and stdout=serial,nc then all output
for serial, e.g. echos of input on serial, will appear on serial and nc.
Just as with the old console code, this statement is still true:
If not defined in the environment, the first input device is assigned
to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
If CONFIG_SYS_CONSOLE_IS_IN_ENV is defined then multiple input/output
devices can be set at boot time if defined in the environment.
CAVEATS
-------
Note that common/iomux.c calls console_assign() for every registered
device as it is discovered. This means that the environment settings
for application consoles will be set to the last device in the list.
On a slow machine, such as MPC852T clocked at 66MHz, the overhead associated
with calling tstc() and then getc() means that copy&paste will normally not
work, even when stdin=stdout=stderr=serial.
On a faster machine, such as a sequoia, cut&paste of longer (about 80
characters) lines works fine when serial is the only device used.
Using nc as a stdin device results in even more overhead because nc_tstc()
is quite slow. Even on a sequoia cut&paste does not work on the serial
interface when nc is added to stdin, although there is no character loss using
the ethernet interface for input. In this test case stdin=serial,nc and
stdout=serial.
In addition, the overhead associated with sending to two devices, when one of
them is nc, also causes problems. Even on a sequoia cut&paste does not work
on the serial interface (stdin=serial) when nc is added to stdout (stdout=
serial,nc).

91
common/package/boot/uboot-ipq40xx/src/doc/README.kmeter1 Normal file
View file

@ -0,0 +1,91 @@
Keymile kmeter1 Board
-----------------------------------------
1. Alternative Boot EEPROM
Upon the kmeter1 startup the I2C_1 controller is used to fetch the boot
configuration from a serial EEPROM. During the development and debugging
phase it might be helpful to apply an alternative boot configuration in
a simple way. Therefore it is an alternative boot eeprom on the PIGGY,
which can be activated by setting the "ST" jumper on the PIGGY board.
2. Memory Map
BaseAddr PortSz Size Device
----------- ------ ----- ------
0x0000_0000 64 bit 256MB DDR
0x8000_0000 8 bit 256KB GPIO/PIGGY on CS1
0xa000_0000 8 bit 256MB PAXE on CS3
0xe000_0000 2MB Int Mem Reg Space
0xf000_0000 16 bit 256MB FLASH on CS0
DDR-SDRAM:
The current realization is made with four 16-bits memory devices.
Mounting options have been foreseen for device architectures from
4Mx16 to 512Mx16. The kmeter1 is equipped with four 32Mx16 devices
thus resulting in a total capacity of 256MBytes.
3. Compilation
Assuming you're using BASH shell:
export CROSS_COMPILE=your-cross-compile-prefix
cd u-boot
make distclean
make kmeter1_config
make
4. Downloading and Flashing Images
4.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
=> run load
Using UEC0 device
TFTP from server 192.168.1.1; our IP address is 192.168.205.4
Filename '/tftpboot/kmeter1/u-boot.bin'.
Load address: 0x200000
Loading: ##############
done
Bytes transferred = 204204 (31dac hex)
=>
4.1 Reflash U-boot Image using U-boot
=> run update
..... done
Un-Protected 5 sectors
..... done
Erased 5 sectors
Copy to Flash... done
..... done
Protected 5 sectors
Total of 204204 bytes were the same
Saving Environment to Flash...
. done
Un-Protected 1 sectors
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... done
. done
Protected 1 sectors
. done
Protected 1 sectors
=>
5. Notes
1) The console baudrate for kmeter1 is 115200bps.

64
common/package/boot/uboot-ipq40xx/src/doc/README.korat Normal file
View file

@ -0,0 +1,64 @@
The Korat board has two NOR flashes, FLASH0 and FLASH1, which are connected to
chip select 0 and 1, respectively. FLASH0 contains 16 MiB, and is mapped to
addresses 0xFF000000 - 0xFFFFFFFF as U-Boot Flash Bank #2. FLASH1 contains
from 16 to 128 MiB, and is mapped to 0xF?000000 - 0xF7FFFFFF as U-Boot Flash
Bank #1 (with the starting address depending on the flash size detected at
runtime). The write-enable pin on FLASH0 is disabled, so the contents of FLASH0
cannot be modified in the field. This also prevents FLASH0 from executing
commands to return chip information, so its configuration is hard-coded in
U-Boot.
There are two versions of U-Boot for Korat: "permanent" and "upgradable". The
permanent U-Boot is pre-programmed at the top of FLASH0, e.g., at addresses
0xFFFA0000 - 0xFFFFFFFF for the current 384 KiB size. The upgradable U-Boot is
located 256 KiB from the top of FLASH1, e.g. at addresses 0xF7F6000 - 0xF7FC0000
for the current 384 KiB size. FLASH1 addresses 0xF7FE0000 - 0xF7FF0000 are
used for the U-Boot environmental parameters, and addresses 0xF7FC0000 -
0xF7FDFFFF are used for the redundant copy of the parameters. These locations
are used by both versions of U-Boot.
On booting, the permanent U-Boot in FLASH0 begins executing. After performing
minimal setup, it monitors the state of the board's Reset switch (GPIO47). If
the switch is sensed as open before a timeout period, then U-Boot branches to
address 0xF7FBFFFC. This causes the upgradable U-Boot to execute from the
beginning. If the switch remains closed thoughout the timeout period, the
permanent U-Boot activates the on-board buzzer until the switch is sensed as
opened. It then continues to execute without branching to FLASH1. The effect
of this is that normally the Korat board boots its upgradable U-Boot, but, if
this has been corrupted, the user can boot the permanent U-Boot, which can then
be used to erase and reload FLASH1 as needed.
Note that it is not necessary for the permanent U-Boot to have all the latest
features, but only that it have sufficient functionality (working "tftp",
"erase", "cp.b", etc.) to repair FLASH1. Also, the permanent U-Boot makes no
assumptions about the size of FLASH1 or the size of the upgradable U-Boot: it is
sufficient that the upgradable U-Boot can be started by a branch to 0xF7FBFFFC.
The build sequence:
make korat_perm_config
make all
builds the permanent U-Boot by selecting loader file "u-boot.lds" and defining
preprocessor symbol "CONFIG_KORAT_PERMANENT". The default build:
make korat_config
make all
creates the upgradable U-Boot by selecting loader file "u-boot-F7FC.lds" and
leaving preprocessor symbol "CONFIG_KORAT_PERMANENT" undefined.
2008-02-22, Larry Johnson <lrj@acm.org>
The CompactFlash(R) controller on the Korat board provides a hi-speed USB
interface. This may be connected to either a dedicated port on the on-board
USB controller, or to a USB port on the PowerPC 440EPx processor. The U-Boot
environment variable "korat_usbcf" can be used to specify which of these two
USB host ports is used for CompactFlash. The valid setting for the variable are
the strings "pci" and "ppc". If the variable defined and set to "ppc", then the
PowerPC USB port is used. In all other cases the on-board USB controller is
used, but if "korat_usbcf" is defined but is set to a string other than the two
valid options, a warning is also issued.
2009-01-28, Larry Johnson <lrj@acm.org>

93
common/package/boot/uboot-ipq40xx/src/doc/README.kwbimage Normal file
View file

@ -0,0 +1,93 @@
---------------------------------------------
Kirkwood Boot Image generation using mkimage
---------------------------------------------
This document describes the U-Boot feature as it
is implemented for the Kirkwood family of SoCs.
The Kirkwood SoC's can boot directly from NAND FLASH,
SPI FLASH, SATA etc. using its internal bootRom support.
for more details refer section 24.2 of Kirkwood functional specifications.
ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
Command syntax:
--------------
./tools/mkimage -l <kwboot_file>
to list the kwb image file details
./tools/mkimage -n <board specific configuration file> \
-T kwbimage -a <start address> -e <execution address> \
-d <input_raw_binary> <output_kwboot_file>
for ex.
./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
-T kwbimage -a 0x00600000 -e 0x00600000 \
-d u-boot.bin u-boot.kwb
kwimage support available with mkimage utility will generate kirkwood boot
image that can be flashed on the board NAND/SPI flash
Board specific configuration file specifications:
------------------------------------------------
1. This file must present in the $(BOARDDIR) and the name should be
kwbimage.cfg (since this is used in Makefile)
2. This file can have empty lines and lines starting with "#" as first
character to put comments
3. This file can have configuration command lines as mentioned below,
any other information in this file is treated as invalid.
Configuration command line syntax:
---------------------------------
1. Each command line is must have two strings, first one command or address
and second one data string
2. Following are the valid command strings and associated data strings:-
Command string data string
-------------- -----------
BOOT_FROM nand/spi/sata
NAND_ECC_MODE default/rs/hamming/disabled
NAND_PAGE_SIZE any uint16_t hex value
SATA_PIO_MODE any uint32_t hex value
DDR_INIT_DELAY any uint32_t hex value
DATA regaddr and regdara hex value
you can have maximum 55 such register programming commands
3. All commands are optional to program
Typical example of kwimage.cfg file:
-----------------------------------
# Boot Media configurations
BOOT_FROM nand
NAND_ECC_MODE default
NAND_PAGE_SIZE 0x0800
# Configure RGMII-0 interface pad voltage to 1.8V
DATA 0xFFD100e0 0x1b1b1b9b
# DRAM Configuration
DATA 0xFFD01400 0x43000c30
DATA 0xFFD01404 0x37543000
DATA 0xFFD01408 0x22125451
DATA 0xFFD0140C 0x00000a33
DATA 0xFFD01410 0x000000cc
DATA 0xFFD01414 0x00000000
DATA 0xFFD01418 0x00000000
DATA 0xFFD0141C 0x00000C52
DATA 0xFFD01420 0x00000040
DATA 0xFFD01424 0x0000F17F
DATA 0xFFD01428 0x00085520
DATA 0xFFD0147C 0x00008552
DATA 0xFFD01504 0x0FFFFFF1
DATA 0xFFD01508 0x10000000
DATA 0xFFD0150C 0x0FFFFFF5
DATA 0xFFD01514 0x00000000
DATA 0xFFD0151C 0x00000000
DATA 0xFFD01494 0x00030000
DATA 0xFFD01498 0x00000000
DATA 0xFFD0149C 0x0000E803
DATA 0xFFD01480 0x00000001
# End of Header extension
DATA 0x0 0x0
------------------------------------------------
Author: Prafulla Wadaskar <prafulla@marvell.com>

75
common/package/boot/uboot-ipq40xx/src/doc/README.link-local Normal file
View file

@ -0,0 +1,75 @@
------------------------------------------
Link-local IP address auto-configuration
------------------------------------------
Negotiate with other link-local clients on the local network
for an address that doesn't require explicit configuration.
This is especially useful if a DHCP server cannot be guaranteed
to exist in all environments that the device must operate.
This is an implementation of RFC3927.
----------
Commands
----------
When CONFIG_CMD_LINK_LOCAL is defined in the board config file,
the "linklocal" command is available. This running this will
take approximately 5 seconds while the address is negotiated.
------------------------
Environment interation
------------------------
The "llipaddr" variable is set with the most recently
negotiated address and is preferred in future negotiations.
The "ipaddr", "netmask", and "gatewayip" variables are set
after successful negotiation to enable network access.
-------------
Limitations
-------------
RFC3927 requires that addresses are continuously checked to
avoid conflicts, however this can only happen when the NetLoop
is getting called. It is possible for a conflict to go undetected
until a command that accesses the network is executed.
Using NetConsole is one way to ensure that NetLoop is always
processing packets and monitoring for conflicts.
This is also not a concern if the feature is use to connect
directly to another machine that may not be running a DHCP server.
----------------
Example script
----------------
This script allows use of DHCP and/or Link-local controlled
by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP,
and CONFIG_BOOTP_MAY_FAIL.
If both fail or are disabled, static settings are used.
#define CONFIG_EXTRA_ENV_SETTINGS \
"ipconfigcmd=if test \\\"$dhcpenabled\\\" -ne 0;" \
"then " \
"dhcpfail=0;dhcp || dhcpfail=1;" \
"else " \
"dhcpfail=-1;" \
"fi;" \
"if test \\\"$linklocalenabled\\\" -ne 0 -a " \
"\\\"$dhcpfail\\\" -ne 0;" \
"then " \
"linklocal;" \
"llfail=0;" \
"else " \
"llfail=-1;" \
"fi;" \
"if test \\\"$llfail\\\" -ne 0 -a " \
"\\\"$dhcpfail\\\" -ne 0; " \
"then " \
"setenv ipaddr $sipaddr; " \
"setenv netmask $snetmask; " \
"setenv gatewayip $sgatewayip; " \
"fi;\0" \

57
common/package/boot/uboot-ipq40xx/src/doc/README.lynxkdi Normal file
View file

@ -0,0 +1,57 @@
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 CONFIG_SYS_IMMR 0xFA200000
#define CONFIG_SYS_BCSR 0xFA100000
#define CONFIG_SYS_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

13
common/package/boot/uboot-ipq40xx/src/doc/README.m28 Normal file
View file

@ -0,0 +1,13 @@
DENX M28EVK
===========
Files of the M28/M28EVK port
----------------------------
arch/arm/cpu/arm926ejs/mx28/ - The CPU support code for the Freescale i.MX28
arch/arm/include/asm/arch-mx28/ - Header files for the Freescale i.MX28
board/denx/m28evk/ - M28EVK board specific files
include/configs/m28evk.h - M28EVK configuration file
Follow the instructions from doc/README.mx28_common to generate a bootable SD
card or to boot from NAND flash.

231
common/package/boot/uboot-ipq40xx/src/doc/README.m52277evb Normal file
View file

@ -0,0 +1,231 @@
Freescale MCF52277EVB ColdFire Development Board
================================================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created Jan 8, 2008
===========================================
Changed files:
==============
- board/freescale/m52277evb/m52277evb.c Dram setup
- board/freescale/m52277evb/Makefile Makefile
- board/freescale/m52277evb/config.mk config make
- board/freescale/m52277evb/u-boot.lds Linker description
- arch/m68k/cpu/mcf5227x/cpu.c cpu specific code
- arch/m68k/cpu/mcf5227x/cpu_init.c FBCS, Mux pins, icache and RTC extra regs
- arch/m68k/cpu/mcf5227x/interrupts.c cpu specific interrupt support
- arch/m68k/cpu/mcf5227x/speed.c system, flexbus, and cpu clock
- arch/m68k/cpu/mcf5227x/Makefile Makefile
- arch/m68k/cpu/mcf5227x/config.mk config make
- arch/m68k/cpu/mcf5227x/start.S start up assembly code
- doc/README.m52277evb This readme file
- drivers/serial/mcfuart.c ColdFire common UART driver
- drivers/rtc/mcfrtc.c Realtime clock Driver
- include/asm-m68k/bitops.h Bit operation function export
- include/asm-m68k/byteorder.h Byte order functions
- include/asm-m68k/crossbar.h CrossBar structure and definition
- include/asm-m68k/dspi.h DSPI structure and definition
- include/asm-m68k/edma.h eDMA structure and definition
- include/asm-m68k/flexbus.h FlexBus structure and definition
- include/asm-m68k/fsl_i2c.h I2C structure and definition
- include/asm-m68k/global_data.h Global data structure
- include/asm-m68k/immap.h ColdFire specific header file and driver macros
- include/asm-m68k/immap_5227x.h mcf5227x specific header file
- include/asm-m68k/io.h io functions
- include/asm-m68k/lcd.h LCD structure and definition
- include/asm-m68k/m5227x.h mcf5227x specific header file
- include/asm-m68k/posix_types.h Posix
- include/asm-m68k/processor.h header file
- include/asm-m68k/ptrace.h Exception structure
- include/asm-m68k/rtc.h Realtime clock header file
- include/asm-m68k/ssi.h SSI structure and definition
- include/asm-m68k/string.h String function export
- include/asm-m68k/timer.h Timer structure and definition
- include/asm-m68k/types.h Data types definition
- include/asm-m68k/uart.h Uart structure and definition
- include/asm-m68k/u-boot.h u-boot structure
- include/configs/M52277EVB.h Board specific configuration file
- arch/m68k/lib/board.c board init function
- arch/m68k/lib/cache.c
- arch/m68k/lib/interrupts Coldfire common interrupt functions
- arch/m68k/lib/m68k_linux.c
- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
- arch/m68k/lib/traps.c Exception init code
1 MCF52277 specific Options/Settings
====================================
1.1 pre-loader is no longer suppoer in this coldfire family
1.2 Configuration settings for M52277EVB Development Board
CONFIG_MCF5227x -- define for all MCF5227x CPUs
CONFIG_M52277 -- define for all Freescale MCF52277 CPUs
CONFIG_M52277EVB -- define for M52277EVB board
CONFIG_MCFUART -- define to use common CF Uart driver
CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
CONFIG_BAUDRATE -- define UART baudrate
CONFIG_MCFRTC -- define to use common CF RTC driver
CONFIG_SYS_MCFRTC_BASE -- provide base address for RTC in immap.h
CONFIG_SYS_RTC_OSCILLATOR -- define RTC clock frequency
RTC_DEBUG -- define to show RTC debug message
CONFIG_CMD_DATE -- enable to use date feature in u-boot
CONFIG_MCFTMR -- define to use DMA timer
CONFIG_MCFPIT -- define to use PIT timer
CONFIG_FSL_I2C -- define to use FSL common I2C driver
CONFIG_HARD_I2C -- define for I2C hardware support
CONFIG_SOFT_I2C -- define for I2C bit-banged
CONFIG_SYS_I2C_SPEED -- define for I2C speed
CONFIG_SYS_I2C_SLAVE -- define for I2C slave address
CONFIG_SYS_I2C_OFFSET -- define for I2C base address offset
CONFIG_SYS_IMMR -- define for MBAR offset
CONFIG_SYS_MBAR -- define MBAR offset
CONFIG_MONITOR_IS_IN_RAM -- Not support
CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF52277 internal SRAM
CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
CONFIG_LCD and CONFIG_CMD_USB are not supported in this current u-boot,
update will be provided at later time
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. System memory map:
Flash: 0x00000000-0x3FFFFFFF (1024MB)
DDR: 0x40000000-0x7FFFFFFF (1024MB)
SRAM: 0x80000000-0x8FFFFFFF (256MB)
IP: 0xF0000000-0xFFFFFFFF (256MB)
2.2. 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:
Flash0: 0x00000000-0x00FFFFFF (16MB)
DDR: 0x40000000-0x4FFFFFFF (64MB)
SRAM: 0x80000000-0x80007FFF (32KB)
IP: 0xFC000000-0xFC0FFFFF (64KB)
3. COMPILATION
==============
3.1 To create U-Boot the gcc-4.1-xx compiler set (ColdFire ELF or
uClinux version) from codesourcery.com was used. Download it from:
http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
3.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot-1.x.x
make distclean
make M52277EVB_config
make
4. SCREEN DUMP
==============
4.1 M52277EVB Development board
(NOTE: May not show exactly the same)
U-Boot 1.3.1 (Jan 8 2008 - 12:44:08)
CPU: Freescale MCF52277 (Mask:6c Version:0)
CPU CLK 160 Mhz BUS CLK 80 Mhz FLB CLK 80 MHZ
INP CLK 16 Mhz VCO CLK 480 Mhz
Board: Freescale 52277 EVB
I2C: ready
DRAM: 64 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
-> print
baudrate=115200
hostname=M52277EVB
inpclk=16000000
loadaddr=(0x40000000 + 0x10000)
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
u-boot=u-boot.bin
stdin=serial
stdout=serial
stderr=serial
mem=65024k
Environment size: 280/32764 bytes
-> bdinfo
memstart = 0x40000000
memsize = 0x04000000
flashstart = 0x00000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x80000000
sramsize = 0x00008000
mbar = 0xFC000000
busfreq = 80 MHz
flbfreq = 80 Mhz
inpfreq = 16 Mhz
vcofreq = 480 Mhz
baudrate = 115200 bps
->
-> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
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
i2c - I2C sub-system
icache - enable or disable instruction cache
iminfo - print header information for application image
imls - list all images found in flash
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
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
source - run script from memory
version - print monitor version
->

103
common/package/boot/uboot-ipq40xx/src/doc/README.m5253evbe Normal file
View file

@ -0,0 +1,103 @@
Freescale Amadeus Plus M5253EVBE board
======================================
Hayden Fraser(Hayden.Fraser@freescale.com)
Created 06/05/2007
===========================================
1. SWITCH SETTINGS
==================
1.1 N/A
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:
SDR: 0x00000000-0x00ffffff
SRAM0: 0x20010000-0x20017fff
SRAM1: 0x20000000-0x2000ffff
MBAR1: 0x10000000-0x4fffffff
MBAR2: 0x80000000-0xCfffffff
Flash: 0xffe00000-0xffffffff
3. DEFINITIONS AND COMPILATION
==============================
3.1 Explanation on NEW definitions in include/configs/M5253EVBE.h
CONFIG_MCF52x2 Processor family
CONFIG_MCF5253 MCF5253 specific
CONFIG_M5253EVBE Amadeus Plus board specific
CONFIG_SYS_CLK Define Amadeus Plus CPU Clock
CONFIG_SYS_MBAR MBAR base address
CONFIG_SYS_MBAR2 MBAR2 base address
3.2 Compilation
export CROSS_COMPILE=/usr/local/freescale-coldfire-4.1-elf/bin/m68k-elf-
cd u-boot-1-2-x
make distclean
make M5253EVBE_config
make
4. SCREEN DUMP
==============
4.1 U-Boot 1.2.0 (Jun 18 2007 - 18:20:00)
CPU: Freescale Coldfire MCF5253 at 62 MHz
Board: Freescale MCF5253 EVBE
DRAM: 16 MB
FLASH: 2 MB
In: serial
Out: serial
Err: serial
=> flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 2 MB in 35 Sectors
AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x49
Erase timeout: 16384 ms, write timeout: 1 ms
Sector Start Addresses:
FFE00000 RO FFE04000 RO FFE06000 RO FFE08000 RO FFE10000 RO
FFE20000 FFE30000 FFE40000 FFE50000 FFE60000
FFE70000 FFE80000 FFE90000 FFEA0000 FFEB0000
FFEC0000 FFED0000 FFEE0000 FFEF0000 FFF00000
FFF10000 FFF20000 FFF30000 FFF40000 FFF50000
FFF60000 FFF70000 FFF80000 FFF90000 FFFA0000
FFFB0000 FFFC0000 FFFD0000 FFFE0000 FFFF0000
=> bdinfo
boot_params = 0x00F62F90
memstart = 0x00000000
memsize = 0x01000000
flashstart = 0xFFE00000
flashsize = 0x00200000
flashoffset = 0x00000000
baudrate = 19200 bps
=> printenv
bootdelay=5
baudrate=19200
stdin=serial
stdout=serial
stderr=serial
Environment size: 134/8188 bytes
=> saveenv
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
=>
5. COMPILER
-----------
To create U-Boot the CodeSourcery's version of the GNU Toolchain for the ColdFire architecture
compiler set (freescale-coldfire-4.1-elf) from www.codesourcery.com was used.
You can download it from:http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
compiler that you used - for example, codesourcery_elf requires -MQ in rules.mk, old M68K 2.95.3 just -M
codesourcery_elf requires -MQ in rules.mk, old M68K 2.95.3 just -M

180
common/package/boot/uboot-ipq40xx/src/doc/README.m53017evb Normal file
View file

@ -0,0 +1,180 @@
Freescale MCF53017EVB ColdFire Development Board
================================================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created 10/22/08
===========================================
Changed files:
==============
- board/freescale/m53017evb/m53017evb.c Dram setup
- board/freescale/m53017evb/mii.c Mii access
- board/freescale/m53017evb/Makefile Makefile
- board/freescale/m53017evb/config.mk config make
- board/freescale/m53017evb/u-boot.lds Linker description
- arch/m68k/cpu/mcf532x/cpu.c cpu specific code
- arch/m68k/cpu/mcf532x/cpu_init.c FBCS, Mux pins, icache and RTC extra regs
- arch/m68k/cpu/mcf532x/interrupts.c cpu specific interrupt support
- arch/m68k/cpu/mcf532x/speed.c system, flexbus, and cpu clock
- arch/m68k/cpu/mcf532x/Makefile Makefile
- arch/m68k/cpu/mcf532x/config.mk config make
- arch/m68k/cpu/mcf532x/start.S start up assembly code
- doc/README.m53017evb This readme file
- drivers/net/mcffec.c ColdFire common FEC driver
- drivers/net/mcfmii.c ColdFire common Mii driver
- drivers/serial/mcfuart.c ColdFire common UART driver
- drivers/rtc/mcfrtc.c Realtime clock Driver
- include/asm-m68k/bitops.h Bit operation function export
- include/asm-m68k/byteorder.h Byte order functions
- include/asm-m68k/fec.h FEC structure and definition
- include/asm-m68k/fsl_i2c.h I2C structure and definition
- include/asm-m68k/global_data.h Global data structure
- include/asm-m68k/immap.h ColdFire specific header file and driver macros
- include/asm-m68k/immap_5301x.h mcf5301x specific header file
- include/asm-m68k/io.h io functions
- include/asm-m68k/m532x.h mcf5301x specific header file
- include/asm-m68k/posix_types.h Posix
- include/asm-m68k/processor.h header file
- include/asm-m68k/ptrace.h Exception structure
- include/asm-m68k/rtc.h Realtime clock header file
- include/asm-m68k/string.h String function export
- include/asm-m68k/timer.h Timer structure and definition
- include/asm-m68k/types.h Data types definition
- include/asm-m68k/uart.h Uart structure and definition
- include/asm-m68k/u-boot.h u-boot structure
- include/configs/M53017EVB.h Board specific configuration file
- arch/m68k/lib/board.c board init function
- arch/m68k/lib/cache.c
- arch/m68k/lib/interrupts Coldfire common interrupt functions
- arch/m68k/lib/m68k_linux.c
- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
- arch/m68k/lib/traps.c Exception init code
1 MCF5301x specific Options/Settings
====================================
1.1 pre-loader is no longer suppoer in thie coldfire family
1.2 Configuration settings for M53017EVB Development Board
CONFIG_MCF5301x -- define for all MCF5301x CPUs
CONFIG_M53015 -- define for MCF53015 CPUs
CONFIG_M53017EVB -- define for M53017EVB board
CONFIG_MCFUART -- define to use common CF Uart driver
CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
CONFIG_BAUDRATE -- define UART baudrate
CONFIG_MCFRTC -- define to use common CF RTC driver
CONFIG_SYS_MCFRTC_BASE -- provide base address for RTC in immap.h
CONFIG_SYS_RTC_OSCILLATOR -- define RTC clock frequency
RTC_DEBUG -- define to show RTC debug message
CONFIG_CMD_DATE -- enable to use date feature in u-boot
CONFIG_MCFFEC -- define to use common CF FEC driver
CONFIG_MII -- enable to use MII driver
CONFIG_CF_DOMII -- enable to use MII feature in cmd_mii.c
CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery
CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer
CONFIG_SYS_FAULT_ECHO_LINK_DOWN --
CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration
CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register
MCFFEC_TOUT_LOOP -- set FEC timeout loop
CONFIG_MCFTMR -- define to use DMA timer
CONFIG_MCFPIT -- define to use PIT timer
CONFIG_FSL_I2C -- define to use FSL common I2C driver
CONFIG_HARD_I2C -- define for I2C hardware support
CONFIG_SOFT_I2C -- define for I2C bit-banged
CONFIG_SYS_I2C_SPEED -- define for I2C speed
CONFIG_SYS_I2C_SLAVE -- define for I2C slave address
CONFIG_SYS_I2C_OFFSET -- define for I2C base address offset
CONFIG_SYS_IMMR -- define for MBAR offset
CONFIG_SYS_MBAR -- define MBAR offset
CONFIG_MONITOR_IS_IN_RAM -- Not support
CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF5301x internal SRAM
CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. System memory map:
Flash: 0x00000000-0x3FFFFFFF (1024MB)
DDR: 0x40000000-0x7FFFFFFF (1024MB)
SRAM: 0x80000000-0x8FFFFFFF (256MB)
IP: 0xFC000000-0xFFFFFFFF (256MB)
2.2. 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:
Flash0: 0x00000000-0x00FFFFFF (16MB)
DDR: 0x40000000-0x4FFFFFFF (256MB)
SRAM: 0x80000000-0x80007FFF (32KB)
IP: 0xFC000000-0xFC0FFFFF (64KB)
3. COMPILATION
==============
3.1 To create U-Boot the gcc-4.x-xx compiler set (ColdFire ELF or
uClinux version) from codesourcery.com was used. Download it from:
http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
3.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot
make distclean
make M53017EVB_config
make
4. SCREEN DUMP
==============
4.1 M53017EVB Development board
(NOTE: May not show exactly the same)
U-Boot 2008.10 (Oct 22 2007 - 11:07:57)
CPU: Freescale MCF53015 (Mask:76 Version:0)
CPU CLK 240 Mhz BUS CLK 80 Mhz
Board: Freescale M53017EVB
I2C: ready
DRAM: 64 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
NAND: 16 MiB
Net: FEC0, FEC1
-> print
bootdelay=1
baudrate=115200
ethaddr=00:e0:0c:bc:e5:60
hostname=M53017EVB
netdev=eth0
loadaddr=40010000
u-boot=u-boot.bin
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
gatewayip=192.168.1.1
netmask=255.255.255.0
ipaddr=192.168.1.3
serverip=192.168.1.2
stdin=serial
stdout=serial
stderr=serial
mem=65024k
Environment size: 437/4092 bytes
->

326
common/package/boot/uboot-ipq40xx/src/doc/README.m5373evb Normal file
View file

@ -0,0 +1,326 @@
Freescale MCF5373EVB ColdFire Development Board
================================================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created 11/08/07
===========================================
Changed files:
==============
- board/freescale/m5373evb/m5373evb.c Dram setup
- board/freescale/m5373evb/mii.c Mii access
- board/freescale/m5373evb/Makefile Makefile
- board/freescale/m5373evb/config.mk config make
- board/freescale/m5373evb/u-boot.lds Linker description
- arch/m68k/cpu/mcf532x/cpu.c cpu specific code
- arch/m68k/cpu/mcf532x/cpu_init.c FBCS, Mux pins, icache and RTC extra regs
- arch/m68k/cpu/mcf532x/interrupts.c cpu specific interrupt support
- arch/m68k/cpu/mcf532x/speed.c system, pci, flexbus, and cpu clock
- arch/m68k/cpu/mcf532x/Makefile Makefile
- arch/m68k/cpu/mcf532x/config.mk config make
- arch/m68k/cpu/mcf532x/start.S start up assembly code
- doc/README.m5373evb This readme file
- drivers/net/mcffec.c ColdFire common FEC driver
- drivers/serial/mcfuart.c ColdFire common UART driver
- drivers/rtc/mcfrtc.c Realtime clock Driver
- include/asm-m68k/bitops.h Bit operation function export
- include/asm-m68k/byteorder.h Byte order functions
- include/asm-m68k/fec.h FEC structure and definition
- include/asm-m68k/fsl_i2c.h I2C structure and definition
- include/asm-m68k/global_data.h Global data structure
- include/asm-m68k/immap.h ColdFire specific header file and driver macros
- include/asm-m68k/immap_532x.h mcf532x specific header file
- include/asm-m68k/io.h io functions
- include/asm-m68k/m532x.h mcf532x specific header file
- include/asm-m68k/posix_types.h Posix
- include/asm-m68k/processor.h header file
- include/asm-m68k/ptrace.h Exception structure
- include/asm-m68k/rtc.h Realtime clock header file
- include/asm-m68k/string.h String function export
- include/asm-m68k/timer.h Timer structure and definition
- include/asm-m68k/types.h Data types definition
- include/asm-m68k/uart.h Uart structure and definition
- include/asm-m68k/u-boot.h u-boot structure
- include/configs/M5373EVB.h Board specific configuration file
- arch/m68k/lib/board.c board init function
- arch/m68k/lib/cache.c
- arch/m68k/lib/interrupts Coldfire common interrupt functions
- arch/m68k/lib/m68k_linux.c
- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
- arch/m68k/lib/traps.c Exception init code
1 MCF5373 specific Options/Settings
====================================
1.1 pre-loader is no longer suppoer in thie coldfire family
1.2 Configuration settings for M5373EVB Development Board
CONFIG_MCF532x -- define for all MCF532x CPUs
CONFIG_M5373 -- define for all Freescale MCF5373 CPUs
CONFIG_M5373EVB -- define for M5373EVB board
CONFIG_MCFUART -- define to use common CF Uart driver
CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
CONFIG_BAUDRATE -- define UART baudrate
CONFIG_MCFRTC -- define to use common CF RTC driver
CONFIG_SYS_MCFRTC_BASE -- provide base address for RTC in immap.h
CONFIG_SYS_RTC_OSCILLATOR -- define RTC clock frequency
RTC_DEBUG -- define to show RTC debug message
CONFIG_CMD_DATE -- enable to use date feature in u-boot
CONFIG_MCFFEC -- define to use common CF FEC driver
CONFIG_MII -- enable to use MII driver
CONFIG_CF_DOMII -- enable to use MII feature in cmd_mii.c
CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery
CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer
CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration
CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register
MCFFEC_TOUT_LOOP -- set FEC timeout loop
CONFIG_MCFTMR -- define to use DMA timer
CONFIG_MCFPIT -- define to use PIT timer
CONFIG_FSL_I2C -- define to use FSL common I2C driver
CONFIG_HARD_I2C -- define for I2C hardware support
CONFIG_SOFT_I2C -- define for I2C bit-banged
CONFIG_SYS_I2C_SPEED -- define for I2C speed
CONFIG_SYS_I2C_SLAVE -- define for I2C slave address
CONFIG_SYS_I2C_OFFSET -- define for I2C base address offset
CONFIG_SYS_IMMR -- define for MBAR offset
CONFIG_SYS_MBAR -- define MBAR offset
CONFIG_MONITOR_IS_IN_RAM -- Not support
CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF5373 internal SRAM
CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. System memory map:
Flash: 0x00000000-0x3FFFFFFF (1024MB)
DDR: 0x40000000-0x7FFFFFFF (1024MB)
SRAM: 0x80000000-0x8FFFFFFF (256MB)
IP: 0xF0000000-0xFFFFFFFF (256MB)
2.2. 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:
Flash0: 0x00000000-0x00FFFFFF (16MB)
DDR: 0x40000000-0x4FFFFFFF (256MB)
SRAM: 0x80000000-0x80007FFF (32KB)
IP: 0xFC000000-0xFC0FFFFF (64KB)
3. COMPILATION
==============
3.1 To create U-Boot the gcc-4.1-xx compiler set (ColdFire ELF or
uClinux version) from codesourcery.com was used. Download it from:
http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
3.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot-1.x.x
make distclean
make M5373EVB_config
make
4. SCREEN DUMP
==============
4.1 M5373EVB Development board
(NOTE: May not show exactly the same)
U-Boot 1.3.0 (Nov 8 2007 - 12:44:08)
CPU: Freescale MCF5373 (Mask:65 Version:1)
CPU CLK 240 Mhz BUS CLK 80 Mhz
Board: Freescale FireEngine 5373 EVB
I2C: ready
DRAM: 32 MB
FLASH: 2 MB
In: serial
Out: serial
Err: serial
NAND: 16 MiB
Net: FEC0
-> print
bootdelay=1
baudrate=115200
ethaddr=00:e0:0c:bc:e5:60
hostname=M5373EVB
netdev=eth0
loadaddr=40010000
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
prog=prot off 0 2ffff;era 0 2ffff;cp.b ${loadaddr} 0 ${filesize};save
ethact=FEC0
u-boot=u-boot.bin
gatewayip=192.168.1.1
netmask=255.255.255.0
ipaddr=192.168.1.3
serverip=192.168.1.2
stdin=serial
stdout=serial
stderr=serial
mem=261632k
Environment size: 401/8188 bytes
-> bdinfo
memstart = 0x40000000
memsize = 0x02000000
flashstart = 0x00000000
flashsize = 0x00200000
flashoffset = 0x00000000
sramstart = 0x80000000
sramsize = 0x00008000
mbar = 0xFC000000
busfreq = 80 MHz
ethaddr = 00:E0:0C:BC:E5:60
ip_addr = 192.168.1.3
baudrate = 115200 bps
->
-> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
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
i2c - I2C sub-system
icache - enable or disable instruction cache
iminfo - print header information for application image
imls - list all images found in flash
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
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
source - run script from memory
tftpboot- boot image via network using TFTP protocol
version - print monitor version
-> tftp 0x40800000 uImage
Using FEC0 device
TFTP from server 192.168.1.3; our IP address is 192.168.1.3 Filename 'uImage'.
Load address: 0x40800000
Loading: #################################################################
#################################################################
##########
done
Bytes transferred = 2053270 (1f5496 hex)
-> bootm 0x40800000
## Booting image at 40800000 ...
Image Name: Linux Kernel Image
Created: 2007-11-07 20:33:08 UTC
Image Type: M68K Linux Kernel Image (gzip compressed)
Data Size: 2053206 Bytes = 2 MB
Load Address: 40020000
Entry Point: 40020000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.22-uc1 (mattw@loa) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-7
uClinux/COLDFIRE(m537x)
COLDFIRE port done by Greg Ungerer, gerg@snapgear.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists. Total pages: 8128 Kernel command line: rootfstype=romfs PID hash table entries: 128 (order: 7, 512 bytes) Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory available: 28092k/32768k RAM, (1788k kernel code, 244k data) Mount-cache hash table entries: 512
NET: Registered protocol family 16
USB-MCF537x: (HOST module) EHCI device is registered
USB-MCF537x: (OTG module) EHCI device is registered
USB-MCF537x: (OTG module) UDC device is registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver version 1.00 ttyS0 at 0xfc060000 (irq = 90) is a builtin ColdFire UART
ttyS1 at 0xfc064000 (irq = 91) is a builtin ColdFire UART
ttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
nbd: registered device at major 43
usbcore: registered new interface driver ub FEC ENET Version 0.2
fec: PHY @ 0x1, ID 0x20005c90 -- DP83848
eth0: ethernet 00:e0:0c:bc:e5:60
uclinux[mtd]: RAM probe address=0x4021c22c size=0x22b000 Creating 1 MTD partitions on "RAM":
0x00000000-0x0022b000 : "ROMfs"
uclinux[mtd]: set ROMfs to be root filesystem NAND device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V 8-b) Scanning device for bad blocks Creating 1 MTD partitions on "NAND 16MiB 3,3V 8-bit":
0x00000000-0x01000000 : "M53xx flash partition 1"
QSPI: spi->max_speed_hz 300000
QSPI: Baud set to 255
SPI: Coldfire master initialized
M537x - Disable UART1 when using Audio
udc: Freescale MCF53xx UDC driver version 27 October 2006 init
udc: MCF53xx USB Device is found. ID=0x5 Rev=0x41 i2c /dev entries driver
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 64k freed (0x401f5000 - 0x40204000) init started: BusyBox v1.00 (2007.11.07-19:57+0000) multi-call binary?Setting e Mounting filesystems
mount: Mounting devpts on /dev/pts failed: No such device
mount: Mounting usbfs on /proc/bus/usb failed: No such file or directory Starting syslogd and klogd Setting up networking on loopback device:
Setting up networking on eth0:
info, udhcpc (v0.9.9-pre) started
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
debug, Sending discover...
debug, Sending discover...
debug, Sending select for 172.27.0.130...
info, Lease of 172.27.0.130 obtained, lease time 43200 deleting routers
route: SIOC[ADD|DEL]RT: No such process
adding dns 172.27.0.1
Starting the boa webserver:
Setting time from ntp server: ntp.cs.strath.ac.uk
ntp.cs.strath.ac.uk: Unknown host
BusyBox v1.00 (2007.11.07-19:57+0000) Built-in shell (msh) Enter 'help' for a list of built-in commands.
#

409
common/package/boot/uboot-ipq40xx/src/doc/README.m54455evb Normal file
View file

@ -0,0 +1,409 @@
Freescale MCF54455EVB ColdFire Development Board
================================================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created 4/08/07
===========================================
Changed files:
==============
- board/freescale/m54455evb/m54455evb.c Dram setup, IDE pre init, and PCI init
- board/freescale/m54455evb/flash.c Atmel and INTEL flash support
- board/freescale/m54455evb/Makefile Makefile
- board/freescale/m54455evb/config.mk config make
- board/freescale/m54455evb/u-boot.lds Linker description
- common/cmd_bdinfo.c Clock frequencies output
- common/cmd_mii.c mii support
- arch/m68k/cpu/mcf5445x/cpu.c cpu specific code
- arch/m68k/cpu/mcf5445x/cpu_init.c Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs
- arch/m68k/cpu/mcf5445x/interrupts.c cpu specific interrupt support
- arch/m68k/cpu/mcf5445x/speed.c system, pci, flexbus, and cpu clock
- arch/m68k/cpu/mcf5445x/Makefile Makefile
- arch/m68k/cpu/mcf5445x/config.mk config make
- arch/m68k/cpu/mcf5445x/start.S start up assembly code
- doc/README.m54455evb This readme file
- drivers/net/mcffec.c ColdFire common FEC driver
- drivers/serial/mcfuart.c ColdFire common UART driver
- include/asm-m68k/bitops.h Bit operation function export
- include/asm-m68k/byteorder.h Byte order functions
- include/asm-m68k/fec.h FEC structure and definition
- include/asm-m68k/fsl_i2c.h I2C structure and definition
- include/asm-m68k/global_data.h Global data structure
- include/asm-m68k/immap.h ColdFire specific header file and driver macros
- include/asm-m68k/immap_5445x.h mcf5445x specific header file
- include/asm-m68k/io.h io functions
- include/asm-m68k/m5445x.h mcf5445x specific header file
- include/asm-m68k/posix_types.h Posix
- include/asm-m68k/processor.h header file
- include/asm-m68k/ptrace.h Exception structure
- include/asm-m68k/rtc.h Realtime clock header file
- include/asm-m68k/string.h String function export
- include/asm-m68k/timer.h Timer structure and definition
- include/asm-m68k/types.h Data types definition
- include/asm-m68k/uart.h Uart structure and definition
- include/asm-m68k/u-boot.h u-boot structure
- include/configs/M54455EVB.h Board specific configuration file
- arch/m68k/lib/board.c board init function
- arch/m68k/lib/cache.c
- arch/m68k/lib/interrupts Coldfire common interrupt functions
- arch/m68k/lib/m68k_linux.c
- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
- arch/m68k/lib/traps.c Exception init code
- rtc/mcfrtc.c Realtime clock Driver
1 MCF5445x specific Options/Settings
====================================
1.1 pre-loader is no longer suppoer in thie coldfire family
1.2 Configuration settings for M54455EVB Development Board
CONFIG_MCF5445x -- define for all MCF5445x CPUs
CONFIG_M54455 -- define for all Freescale MCF54455 CPUs
CONFIG_M54455EVB -- define for M54455EVB board
CONFIG_MCFUART -- define to use common CF Uart driver
CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
CONFIG_BAUDRATE -- define UART baudrate
CONFIG_MCFRTC -- define to use common CF RTC driver
CONFIG_SYS_MCFRTC_BASE -- provide base address for RTC in immap.h
CONFIG_SYS_RTC_OSCILLATOR -- define RTC clock frequency
RTC_DEBUG -- define to show RTC debug message
CONFIG_CMD_DATE -- enable to use date feature in u-boot
CONFIG_MCFFEC -- define to use common CF FEC driver
CONFIG_MII -- enable to use MII driver
CONFIG_CF_DOMII -- enable to use MII feature in cmd_mii.c
CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery
CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer
CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration
CONFIG_SYS_FEC1_PINMUX -- Set FEC1 Pin configuration
CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register
CONFIG_SYS_FEC1_MIIBASE -- Set FEC0 MII base register
MCFFEC_TOUT_LOOP -- set FEC timeout loop
CONFIG_HAS_ETH1 -- define to enable second FEC in u-boot
CONFIG_ISO_PARTITION -- enable ISO read/write
CONFIG_DOS_PARTITION -- enable DOS read/write
CONFIG_IDE_RESET -- define ide_reset()
CONFIG_IDE_PREINIT -- define ide_preinit()
CONFIG_ATAPI -- define ATAPI support
CONFIG_LBA48 -- define LBA48 (larger than 120GB) support
CONFIG_SYS_IDE_MAXBUS -- define max channel
CONFIG_SYS_IDE_MAXDEVICE -- define max devices per channel
CONFIG_SYS_ATA_BASE_ADDR -- define ATA base address
CONFIG_SYS_ATA_IDE0_OFFSET -- define ATA IDE0 offset
CONFIG_SYS_ATA_DATA_OFFSET -- define ATA data IO
CONFIG_SYS_ATA_REG_OFFSET -- define for normal register accesses
CONFIG_SYS_ATA_ALT_OFFSET -- define for alternate registers
CONFIG_SYS_ATA_STRIDE -- define for Interval between registers
_IO_BASE -- define for IO base address
CONFIG_MCFTMR -- define to use DMA timer
CONFIG_MCFPIT -- define to use PIT timer
CONFIG_FSL_I2C -- define to use FSL common I2C driver
CONFIG_HARD_I2C -- define for I2C hardware support
CONFIG_SOFT_I2C -- define for I2C bit-banged
CONFIG_SYS_I2C_SPEED -- define for I2C speed
CONFIG_SYS_I2C_SLAVE -- define for I2C slave address
CONFIG_SYS_I2C_OFFSET -- define for I2C base address offset
CONFIG_SYS_IMMR -- define for MBAR offset
CONFIG_PCI -- define for PCI support
CONFIG_PCI_PNP -- define for Plug n play support
CONFIG_SYS_PCI_MEM_BUS -- PCI memory logical offset
CONFIG_SYS_PCI_MEM_PHYS -- PCI memory physical offset
CONFIG_SYS_PCI_MEM_SIZE -- PCI memory size
CONFIG_SYS_PCI_IO_BUS -- PCI IO logical offset
CONFIG_SYS_PCI_IO_PHYS -- PCI IO physical offset
CONFIG_SYS_PCI_IO_SIZE -- PCI IO size
CONFIG_SYS_PCI_CFG_BUS -- PCI Configuration logical offset
CONFIG_SYS_PCI_CFG_PHYS -- PCI Configuration physical offset
CONFIG_SYS_PCI_CFG_SIZE -- PCI Configuration size
CONFIG_EXTRA_CLOCK -- Enable extra clock such as vco, flexbus, pci, etc
CONFIG_SYS_MBAR -- define MBAR offset
CONFIG_SYS_ATMEL_BOOT -- To determine the u-boot is booted from Atmel or Intel
CONFIG_MONITOR_IS_IN_RAM -- Not support
CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF54455 internal SRAM
CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
CONFIG_SYS_ATMEL_BASE -- defines the Atmel Flash base
CONFIG_SYS_INTEL_BASE -- defines the Intel Flash base
CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
CONFIG_SYS_SDRAM_BASE1 -- defines the DRAM Base 1
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. System memory map:
Flash: 0x00000000-0x3FFFFFFF (1024MB)
DDR: 0x40000000-0x7FFFFFFF (1024MB)
SRAM: 0x80000000-0x8FFFFFFF (256MB)
ATA: 0x90000000-0x9FFFFFFF (256MB)
PCI: 0xA0000000-0xBFFFFFFF (512MB)
FlexBus: 0xC0000000-0xDFFFFFFF (512MB)
IP: 0xF0000000-0xFFFFFFFF (256MB)
2.2. 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:
Atmel boot:
Flash0: 0x00000000-0x0007FFFF (512KB)
Flash1: 0x04000000-0x05FFFFFF (32MB)
Intel boot:
Flash0: 0x00000000-0x01FFFFFF (32MB)
Flash1: 0x04000000-0x0407FFFF (512KB)
CPLD: 0x08000000-0x08FFFFFF (16MB)
FPGA: 0x09000000-0x09FFFFFF (16MB)
DDR: 0x40000000-0x4FFFFFFF (256MB)
SRAM: 0x80000000-0x80007FFF (32KB)
IP: 0xFC000000-0xFC0FFFFF (64KB)
3. SWITCH SETTINGS
==================
3.1 SW1 Pin3: 0 - Boot from Atmel or 1 - INTEL
SW1 Pin4: 0 - ULPI chip not in reset state or 1 - ULPI chip in reset state
SW1 Pin5: 0 - Full ATA Bus enabled, FEC Phy1 powered down
1 - Upper 8 bits ATA data bus disabled, FEC PHY1 active
SW1 Pin6: 0 - FEC Phy0 active or 1 - FEC Phy0 powered down
SW1 Pin3: 0 - Boot from Atmel or 1 - INTEL
4. COMPILATION
==============
4.1 To create U-Boot the gcc-4.1-32 compiler set (ColdFire ELF version)
from codesourcery.com was used. Download it from:
http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
4.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot-1.x.x
make distclean
make M54455EVB_config, or - default to atmel 33Mhz input clock
make M54455EVB_atmel_config, or - default to atmel 33Mhz input clock
make M54455EVB_a33_config, or - default to atmel 33Mhz input clock
make M54455EVB_a66_config, or - default to atmel 66Mhz input clock
make M54455EVB_intel_config, or - default to intel 33Mhz input clock
make M54455EVB_i33_config, or - default to intel 33Mhz input clock
make M54455EVB_i66_config, or - default to intel 66Mhz input clock
make
5. SCREEN DUMP
==============
5.1 M54455EVB Development board
Boot from Atmel (NOTE: May not show exactly the same)
U-Boot 1.2.0-g98c80b46-dirty (Jul 26 2007 - 12:44:08)
CPU: Freescale MCF54455 (Mask:48 Version:1)
CPU CLK 266 Mhz BUS CLK 133 Mhz FLB CLK 66 Mhz
PCI CLK 33 Mhz INP CLK 33 Mhz VCO CLK 533 Mhz
Board: Freescale M54455 EVB
I2C: ready
DRAM: 256 MB
FLASH: 16.5 MB
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
IDE: Bus 0: not available
-> print
bootargs=root=/dev/ram rw
bootdelay=1
baudrate=115200
ethaddr=00:e0:0c:bc:e5:60
eth1addr=00:e0:0c:bc:e5:61
hostname=M54455EVB
netdev=eth0
inpclk=33333333
loadaddr=40010000
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
prog=prot off 0 2ffff;era 0 2ffff;cp.b ${loadaddr} 0 ${filesize};save
ethact=FEC0
mtdids=nor0=M54455EVB-1
mtdparts=M54455EVB-1:16m(user)
u-boot=u-boot54455.bin
filesize=292b4
fileaddr=40010000
gatewayip=192.168.1.1
netmask=255.255.255.0
ipaddr=192.168.1.3
serverip=192.168.1.2
stdin=serial
stdout=serial
stderr=serial
mem=261632k
Environment size: 563/8188 bytes
-> bdinfo
memstart = 0x40000000
memsize = 0x10000000
flashstart = 0x00000000
flashsize = 0x01080000
flashoffset = 0x00000000
sramstart = 0x80000000
sramsize = 0x00008000
mbar = 0xFC000000
busfreq = 133.333 MHz
pcifreq = 33.333 MHz
flbfreq = 66.666 MHz
inpfreq = 33.333 MHz
vcofreq = 533.333 MHz
ethaddr = 00:E0:0C:BC:E5:60
eth1addr = 00:E0:0C:BC:E5:61
ip_addr = 192.168.1.3
baudrate = 115200 bps
->
-> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
dcache - enable or disable data cache
diskboot- boot from IDE device
echo - echo args to console
erase - erase FLASH memory
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
flinfo - print FLASH memory information
fsinfo - print information about filesystems
fsload - load binary file from a filesystem image
go - start application at address 'addr'
help - print online help
i2c - I2C sub-system
icache - enable or disable instruction cache
ide - IDE sub-system
iminfo - print header information for application image
imls - list all images found in flash
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
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
source - run script from memory
tftpboot- boot image via network using TFTP protocol
version - print monitor version
->bootm 4000000
## Booting image at 04000000 ...
Image Name: Linux Kernel Image
Created: 2007-08-14 15:13:00 UTC
Image Type: M68K Linux Kernel Image (uncompressed)
Data Size: 2301952 Bytes = 2.2 MB
Load Address: 40020000
Entry Point: 40020000
Verifying Checksum ... OK
OK
Linux version 2.6.20-gfe5136d6-dirty (mattw@kea) (gcc version 4.2.0 20070318 (pr
erelease) (Sourcery G++ Lite 4.2-20)) #108 Mon Aug 13 13:00:13 MDT 2007
starting up linux startmem 0xc0254000, endmem 0xcfffffff, size 253MB
Built 1 zonelists. Total pages: 32624
Kernel command line: root=/dev/mtdblock1 rw rootfstype=jffs2 ip=none mtdparts=ph
ysmap-flash.0:5M(kernel)ro,-(jffs2)
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 4, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 3, 65536 bytes)
Memory: 257496k/262136k available (1864k kernel code, 2440k data, 88k init)
Mount-cache hash table entries: 1024
NET: Registered protocol family 16
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 0, 8192 bytes)
TCP established hash table entries: 8192 (order: 2, 32768 bytes)
TCP bind hash table entries: 4096 (order: 1, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver version 1.00
ttyS0 at 0xfc060000 (irq = 90) is a builtin ColdFire UART
ttyS1 at 0xfc064000 (irq = 91) is a builtin ColdFire UART
ttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 8 devices)
FEC ENET Version 0.2
fec: PHY @ 0x0, ID 0x20005ca2 -- DP83849
eth0: ethernet 00:08:ee:00:e4:19
physmap platform flash device: 01000000 at 04000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
2 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 2 MTD partitions on "physmap-flash.0":
0x00000000-0x00500000 : "kernel"
mtd: Giving out device 0 to kernel
0x00500000-0x01000000 : "jffs2"
mtd: Giving out device 1 to jffs2
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
VFS: Mounted root (jffs2 filesystem).
Setting the hostname to freescale
Mounting filesystems
mount: Mounting usbfs on /proc/bus/usb failed: No such file or directory
Starting syslogd and klogd
Setting up networking on loopback device:
Setting up networking on eth0:
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
Adding static route for default gateway to 172.27.255.254:
Setting nameserver to 172.27.0.1 in /etc/resolv.conf:
Starting inetd:
/ #

272
common/package/boot/uboot-ipq40xx/src/doc/README.m5475evb Normal file
View file

@ -0,0 +1,272 @@
Freescale MCF5475EVB ColdFire Development Board
================================================
TsiChung Liew(Tsi-Chung.Liew@freescale.com)
Created Jan 08, 2008
===========================================
Changed files:
==============
- board/freescale/m547xevb/m547xevb.c Dram setup, IDE pre init, and PCI init
- board/freescale/m547xevb/mii.c MII init
- board/freescale/m547xevb/Makefile Makefile
- board/freescale/m547xevb/config.mk config make
- board/freescale/m547xevb/u-boot.lds Linker description
- arch/m68k/cpu/mcf547x_8x/cpu.c cpu specific code
- arch/m68k/cpu/mcf547x_8x/cpu_init.c Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs
- arch/m68k/cpu/mcf547x_8x/interrupts.c cpu specific interrupt support
- arch/m68k/cpu/mcf547x_8x/slicetimer.c Timer support
- arch/m68k/cpu/mcf547x_8x/speed.c system, pci, flexbus, and cpu clock
- arch/m68k/cpu/mcf547x_8x/Makefile Makefile
- arch/m68k/cpu/mcf547x_8x/config.mk config make
- arch/m68k/cpu/mcf547x_8x/start.S start up assembly code
- doc/README.m5475evb This readme file
- drivers/dma/MCD_dmaApi.c DMA API functions
- drivers/dma/MCD_tasks.c DMA Tasks
- drivers/dma/MCD_tasksInit.c DMA Tasks Init
- drivers/net/fsl_mcdmafec.c ColdFire common DMA FEC driver
- drivers/serial/mcfuart.c ColdFire common UART driver
- include/MCD_dma.h DMA header file
- include/MCD_progCheck.h DMA header file
- include/MCD_tasksInit.h DMA header file
- include/asm-m68k/bitops.h Bit operation function export
- include/asm-m68k/byteorder.h Byte order functions
- include/asm-m68k/errno.h Error Number definition
- include/asm-m68k/fec.h FEC structure and definition
- include/asm-m68k/fsl_i2c.h I2C structure and definition
- include/asm-m68k/fsl_mcddmafec.h DMA FEC structure and definition
- include/asm-m68k/global_data.h Global data structure
- include/asm-m68k/immap.h ColdFire specific header file and driver macros
- include/asm-m68k/immap_547x_8x.h mcf547x_8x specific header file
- include/asm-m68k/io.h io functions
- include/asm-m68k/m547x_8x.h mcf547x_8x specific header file
- include/asm-m68k/posix_types.h Posix
- include/asm-m68k/processor.h header file
- include/asm-m68k/ptrace.h Exception structure
- include/asm-m68k/rtc.h Realtime clock header file
- include/asm-m68k/string.h String function export
- include/asm-m68k/timer.h Timer structure and definition
- include/asm-m68k/types.h Data types definition
- include/asm-m68k/uart.h Uart structure and definition
- include/asm-m68k/u-boot.h u-boot structure
- include/configs/M5475EVB.h Board specific configuration file
- arch/m68k/lib/board.c board init function
- arch/m68k/lib/cache.c
- arch/m68k/lib/interrupts Coldfire common interrupt functions
- arch/m68k/lib/m68k_linux.c
- arch/m68k/lib/traps.c Exception init code
1 MCF547x specific Options/Settings
====================================
1.1 pre-loader is no longer suppoer in thie coldfire family
1.2 Configuration settings for M5475EVB Development Board
CONFIG_MCF547x_8x -- define for all MCF547x_8x CPUs
CONFIG_M547x -- define for all Freescale MCF547x CPUs
CONFIG_M5475 -- define for M5475EVB board
CONFIG_MCFUART -- define to use common CF Uart driver
CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
CONFIG_BAUDRATE -- define UART baudrate
CONFIG_FSLDMAFEC -- define to use common dma FEC driver
CONFIG_MII -- enable to use MII driver
CONFIG_CF_DOMII -- enable to use MII feature in cmd_mii.c
CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery
CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer
CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration
CONFIG_SYS_FEC1_PINMUX -- Set FEC1 Pin configuration
CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register
CONFIG_SYS_FEC1_MIIBASE -- Set FEC0 MII base register
MCFFEC_TOUT_LOOP -- set FEC timeout loop
CONFIG_HAS_ETH1 -- define to enable second FEC in u-boot
CONFIG_CMD_USB -- enable USB commands
CONFIG_USB_OHCI_NEW -- enable USB OHCI driver
CONFIG_USB_STORAGE -- enable USB Storage device
CONFIG_DOS_PARTITION -- enable DOS read/write
CONFIG_SLTTMR -- define to use SLT timer
CONFIG_FSL_I2C -- define to use FSL common I2C driver
CONFIG_HARD_I2C -- define for I2C hardware support
CONFIG_SOFT_I2C -- define for I2C bit-banged
CONFIG_SYS_I2C_SPEED -- define for I2C speed
CONFIG_SYS_I2C_SLAVE -- define for I2C slave address
CONFIG_SYS_I2C_OFFSET -- define for I2C base address offset
CONFIG_SYS_IMMR -- define for MBAR offset
CONFIG_PCI -- define for PCI support
CONFIG_PCI_PNP -- define for Plug n play support
CONFIG_SKIPPCI_HOSTBRIDGE -- SKIP PCI Host bridge
CONFIG_SYS_PCI_MEM_BUS -- PCI memory logical offset
CONFIG_SYS_PCI_MEM_PHYS -- PCI memory physical offset
CONFIG_SYS_PCI_MEM_SIZE -- PCI memory size
CONFIG_SYS_PCI_IO_BUS -- PCI IO logical offset
CONFIG_SYS_PCI_IO_PHYS -- PCI IO physical offset
CONFIG_SYS_PCI_IO_SIZE -- PCI IO size
CONFIG_SYS_PCI_CFG_BUS -- PCI Configuration logical offset
CONFIG_SYS_PCI_CFG_PHYS -- PCI Configuration physical offset
CONFIG_SYS_PCI_CFG_SIZE -- PCI Configuration size
CONFIG_SYS_MBAR -- define MBAR offset
CONFIG_MONITOR_IS_IN_RAM -- Not support
CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF547x internal SRAM
CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
===========================================
2.1. System memory map:
Flash: 0xFF800000-0xFFFFFFFF (8MB)
DDR: 0x00000000-0x3FFFFFFF (1024MB)
SRAM: 0xF2000000-0xF2000FFF (4KB)
PCI: 0x70000000-0x8FFFFFFF (512MB)
IP: 0xF0000000-0xFFFFFFFF (256MB)
3. COMPILATION
==============
3.1 To create U-Boot the gcc-4.x compiler set (ColdFire ELF or uclinux
version) from codesourcery.com was used. Download it from:
http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
3.2 Compilation
export CROSS_COMPILE=cross-compile-prefix
cd u-boot-1.x.x
make distclean
make M5475AFE_config, or - boot 2MB, RAM 64MB
make M5475BFE_config, or - boot 2MB, code 16MB, RAM 64MB
make M5475CFE_config, or - boot 2MB, code 16MB, Video, USB, RAM 64MB
make M5475DFE_config, or - boot 2MB, USB, RAM 64MB
make M5475EFE_config, or - boot 2MB, Video, USB, RAM 64MB
make M5475FFE_config, or - boot 2MB, code 32MB, Video, USB, RAM 128MB
make M5475GFE_config, or - boot 2MB, RAM 64MB
make
5. SCREEN DUMP
==============
5.1
U-Boot 1.3.1 (Jan 8 2008 - 12:47:44)
CPU: Freescale MCF5475
CPU CLK 266 Mhz BUS CLK 133 Mhz
Board: Freescale FireEngine 5475 EVB
I2C: ready
DRAM: 64 MB
FLASH: 18 MB
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
-> pri
bootdelay=1
baudrate=115200
ethaddr=00:e0:0c:bc:e5:60
eth1addr=00:e0:0c:bc:e5:61
ipaddr=192.162.1.2
serverip=192.162.1.1
gatewayip=192.162.1.1
netmask=255.255.255.0
hostname=M547xEVB
netdev=eth0
loadaddr=10000
u-boot=u-boot.bin
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
prog=prot off bank 1;era ff800000 ff82ffff;cp.b ${loadaddr} ff800000 ${filesize};save
stdin=serial
stdout=serial
stderr=serial
ethact=FEC0
mem=65024k
Environment size: 433/8188 bytes
-> bdin
memstart = 0x00000000
memsize = 0x04000000
flashstart = 0xFF800000
flashsize = 0x01200000
flashoffset = 0x00000000
sramstart = 0xF2000000
sramsize = 0x00001000
mbar = 0xF0000000
busfreq = 133.333 MHz
pcifreq = 0 MHz
ethaddr = 00:E0:0C:BC:E5:60
eth1addr = 00:E0:0C:BC:E5:61
ip_addr = 192.162.1.2
baudrate = 115200 bps
-> ?
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
cmp - memory compare
coninfo - print console devices and information
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
i2c - I2C sub-system
icache - enable or disable instruction cache
iminfo - print header information for application image
imls - list all images found in flash
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
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
source - run script from memory
tftpboot- boot image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version
-> usb start
(Re)start USB...
USB: OHCI pci controller (1131, 1561) found @(0:17:0)
OHCI regs address 0x80000000
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
->

166
common/package/boot/uboot-ipq40xx/src/doc/README.m68k Normal file
View file

@ -0,0 +1,166 @@
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: arch/m68k/cpu/mcf52x2
2.1 Motorola Coldfire MCF5282
-----------------------------
CPU specific code is located in: arch/m68k/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 CONFIG_SYS_TEXT_BASE in board/m5282evb/config.mk and CONFIG_SYS_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 (CONFIG_SYS_MONITOR_BASE) and Makefile
(CONFIG_SYS_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
CONFIG_SYS_MBAR -- defines the base address of the MCF5272 configuration registers
CONFIG_SYS_INIT_RAM_ADDR
-- defines the base address of the MCF5272 internal SRAM
CONFIG_SYS_ENET_BD_BASE
-- defines the base address of the FEC buffer descriptors
CONFIG_SYS_SCR -- defines the contents of the System Configuration Register
CONFIG_SYS_SPR -- defines the contents of the System Protection Register
CONFIG_SYS_BRx_PRELIM -- defines the contents of the Chip Select Base Registers
CONFIG_SYS_ORx_PRELIM -- defines the contents of the Chip Select Option Registers
CONFIG_SYS_PxDDR -- defines the contents of the Data Direction Registers
CONFIG_SYS_PxDAT -- defines the contents of the Data Registers
CONFIG_SYS_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
CONFIG_SYS_MBAR -- defines the base address of the MCF5282 internal register space
CONFIG_SYS_INIT_RAM_ADDR
-- defines the base address of the MCF5282 internal SRAM
CONFIG_SYS_INT_FLASH_BASE
-- defines the base address of the MCF5282 internal Flash memory
CONFIG_SYS_ENET_BD_BASE
-- defines the base address of the FEC buffer descriptors
CONFIG_SYS_MFD
-- defines the PLL Multiplication Factor Devider
(see table 9-4 of MCF user manual)
CONFIG_SYS_RFD -- defines the PLL Reduce Frecuency Devider
(see table 9-4 of MCF user manual)
CONFIG_SYS_CSx_BASE -- defines the base address of chip select x
CONFIG_SYS_CSx_SIZE -- defines the memory size (address range) of chip select x
CONFIG_SYS_CSx_WIDTH -- defines the bus with of chip select x
CONFIG_SYS_CSx_RO -- if set to 0 chip select x is read/wirte
else chipselct is read only
CONFIG_SYS_CSx_WS -- defines the number of wait states of chip select x
CONFIG_SYS_PxDDR -- defines the contents of the Data Direction Registers
CONFIG_SYS_PxDAT -- defines the contents of the Data Registers
CONFIG_SYS_PXCNT -- defines the contents of the Port Configuration Registers
CONFIG_SYS_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/

65
common/package/boot/uboot-ipq40xx/src/doc/README.marubun-pcmcia Normal file
View file

@ -0,0 +1,65 @@
U-Boot MARUBUN MR-SHPC-01 PCMCIA controller driver
Last update 21/11/2007 by Nobuhiro Iwamatsu
========================================================================================
0. What's this?
This driver supports MARUBUN MR-SHPC-01.
url: http://www.marubun.co.jp/product/semicon/devices/qgc18e0000002n2z.html
(Sorry Japanese only.)
This chip is used with SuperH well, and adopted by the
reference board.
ex. * MS7750SE01
* MS7722SE01
* other
This chip doesn't support CardBus.
1. base source code
The code is based on sources from the Linux kernel
( arch/sh/kernel/cf-enabler.c ).
2. How to use
The options you have to specify in the config file are (with the
value for my board as an example):
* CONFIG_MARUBUN_PCCARD
If you want to use this device driver, should define CONFIG_MARUBUN_PCCARD.
ex. #define CONFIG_MARUBUN_PCCARD
* CONFIG_PCMCIA_SLOT_A
Most devices have only one slot. You should define CONFIG_PCMCIA_SLOT_A .
ex. #define CONFIG_PCMCIA_SLOT_A 1
* CONFIG_SYS_MARUBUN_MRSHPC
This is MR-SHPC-01 PCMCIA controler base address.
You should do the setting matched to your environment.
ex. #define CONFIG_SYS_MARUBUN_MRSHPC 0xb03fffe0
( for MS7722SE01 environment )
* CONFIG_SYS_MARUBUN_MW1
This is MR-SHPC-01 memory window base address.
You should do the setting matched to your environment.
ex. #define CONFIG_SYS_MARUBUN_MW1 0xb0400000
( for MS7722SE01 environment )
* CONFIG_SYS_MARUBUN_MW1
This is MR-SHPC-01 attribute window base address.
You should do the setting matched to your environment.
ex. #define CONFIG_SYS_MARUBUN_MW2 0xb0500000
( for MS7722SE01 environment )
* CONFIG_SYS_MARUBUN_MW1
This is MR-SHPC-01 I/O window base address.
You should do the setting matched to your environment.
ex. #define CONFIG_SYS_MARUBUN_IO 0xb0600000
( for MS7722SE01 environment )
3. Other
* Check Compact Flash only.
* Maybe, NE2000 compatible NIC is sure to move.
Copyright (c) 2007
Nobuhiro Iwamatsu <iwamatsu@nigaur.org>

129
common/package/boot/uboot-ipq40xx/src/doc/README.menu Normal file
View file

@ -0,0 +1,129 @@
/*
* Copyright 2010-2011 Calxeda, Inc.
*
* 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 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, see <http://www.gnu.org/licenses/>.
*/
U-boot provides a set of interfaces for creating and using simple, text
based menus. Menus are displayed as lists of labeled entries on the
console, and an entry can be selected by entering its label.
To use the menu code, enable CONFIG_MENU, and include "menu.h" where
the interfaces should be available.
Menus are composed of items. Each item has a key used to identify it in
the menu, and an opaque pointer to data controlled by the consumer.
If you want to show a menu, instead starting the shell, define
CONFIG_MENU_SHOW. You have to code the int menu_show(int bootdelay)
function, which handle your menu. This function returns the remaining
bootdelay.
Interfaces
----------
#include "menu.h"
/*
* Consumers of the menu interfaces will use a struct menu * as the
* handle for a menu. struct menu is only fully defined in menu.c,
* preventing consumers of the menu interfaces from accessing its
* contents directly.
*/
struct menu;
/*
* NOTE: See comments in common/menu.c for more detailed documentation on
* these interfaces.
*/
/*
* menu_create() - Creates a menu handle with default settings
*/
struct menu *menu_create(char *title, int timeout, int prompt,
void (*item_data_print)(void *));
/*
* menu_item_add() - Adds or replaces a menu item
*/
int menu_item_add(struct menu *m, char *item_key, void *item_data);
/*
* menu_default_set() - Sets the default choice for the menu
*/
int menu_default_set(struct menu *m, char *item_key);
/*
* menu_get_choice() - Returns the user's selected menu entry, or the
* default if the menu is set to not prompt or the timeout expires.
*/
int menu_get_choice(struct menu *m, void **choice);
/*
* menu_destroy() - frees the memory used by a menu and its items.
*/
int menu_destroy(struct menu *m);
/*
* menu_display_statusline(struct menu *m);
* shows a statusline for every menu_display call.
*/
void menu_display_statusline(struct menu *m);
Example Code
------------
This example creates a menu that always prompts, and allows the user
to pick from a list of tools. The item key and data are the same.
#include "menu.h"
char *tools[] = {
"Hammer",
"Screwdriver",
"Nail gun",
NULL
};
char *pick_a_tool(void)
{
struct menu *m;
int i;
char *tool = NULL;
m = menu_create("Tools", 0, 1, NULL);
for(i = 0; tools[i]; i++) {
if (menu_item_add(m, tools[i], tools[i]) != 1) {
printf("failed to add item!");
menu_destroy(m);
return NULL;
}
}
if (menu_get_choice(m, (void **)&tool) != 1)
printf("Problem picking tool!\n");
menu_destroy(m);
return tool;
}
void caller(void)
{
char *tool = pick_a_tool();
if (tool) {
printf("picked a tool: %s\n", tool);
use_tool(tool);
}
}

59
common/package/boot/uboot-ipq40xx/src/doc/README.mergerbox Normal file
View file

@ -0,0 +1,59 @@
Matrix Vision MergerBox
-----------------------
1. Board Description
The MergerBox is a 120x160mm single board computing platform
for 3D Full-HD digital video processing.
Power Supply is 10-32VDC.
2 System Components
2.1 CPU
Freescale MPC8377 CPU running at 800MHz core and 333MHz csb.
256 MByte DDR-II memory @ 333MHz data rate.
64 MByte Nor Flash on local bus.
1 GByte Nand Flash on FCM.
1 Vitesse VSC8601 RGMII ethernet Phys.
1 USB host controller over ULPI I/F with 4-Port hub.
2 serial ports. Console running on ttyS0 @ 115200 8N1.
1 mPCIe expansion slot (PCIe x1 + USB) used for Wifi/Bt.
2 PCIe x1 busses on local mPCIe and cutom expansion connector.
2 SATA host ports.
System configuration (HRCW) is taken from I2C EEPROM.
2.2 Graphics
SM107 emebedded video controller driving a 5" 800x480 TFT panel.
Connected over 32-Bit/66MHz PCI utilizing 4 MByte embedded memory.
2.3 FPGA
Altera Cyclone-IV EP4C115 with several PCI DMA engines.
Connects to 7x Gennum 3G-SDI transceivers as video interconnect
as well as a HDMI v1.4 compliant output for 3D monitoring.
Utilizes two more DDR-II controllers providing 256MB memory.
2.4 I2C
Bus1:
AD7418 @ 0x50 for voltage/temp. monitoring.
SX8650 @ 0x90 touch controller for HMI.
EEPROM @ 0xA0 for system setup (HRCW etc.) + vendor specifics.
Bus2:
mPCIe SMBus
SiI9022A @ 0x72/0xC0 HDMI transmitter.
TCA6416A @ 0x40 + 0x42 16-Bit I/O expander.
LMH1983 @ 0xCA video PLL.
DS1338C @ 0xD0 real-time clock with embedded crystal.
9FG104 @ 0xDC 4x 100MHz LVDS SerDes reference clock.
3 Flash layout.
reset vector is 0x00000100, i.e. low boot.
00000000 u-boot binary.
00100000 FPGA raw bit file.
00300000 FIT image holding kernel, dtb and rescue squashfs.
03d00000 u-boot environment.
03e00000 splash image
mtd partitions are propagated to linux kernel via device tree blob.

57
common/package/boot/uboot-ipq40xx/src/doc/README.mips Normal file
View file

@ -0,0 +1,57 @@
Notes for the MIPS architecture port of U-Boot
Toolchains
----------
http://www.denx.de/wiki/DULG/ELDK
ELDK < DULG < DENX
http://www.emdebian.org/crosstools.html
Embedded Debian -- Cross-development toolchains
http://buildroot.uclibc.org/
Buildroot
Known Issues
------------
* Little endian build problem
If use non-ELDK toolchains, -EB will be set to CPPFLAGS. Therefore all
objects will be generated in big-endian format.
* Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c
Cache will be disabled before entering the loaded ELF image without
writing back and invalidating cache lines. This leads to cache
incoherency in most cases, unless the code gets loaded after U-Boot
re-initializes the cache. The more common uImage 'bootm' command does
not suffer this problem.
[workaround] To avoid this cache incoherency,
1) insert flush_cache(all) before calling dcache_disable(), or
2) fix dcache_disable() to do both flushing and disabling cache.
* Note that Linux users need to kill dcache_disable() in do_bootelf_exec()
or override do_bootelf_exec() not to disable I-/D-caches, because most
Linux/MIPS ports don't re-enable caches after entering kernel_entry.
TODOs
-----
* Probe CPU types, I-/D-cache and TLB size etc. automatically
* Secondary cache support missing
* Centralize the link directive files
* Initialize TLB entries redardless of their use
* R2000/R3000 class parts are not supported
* Limited testing across different MIPS variants
* Due to cache initialization issues, the DRAM on board must be
initialized in board specific assembler language before the cache init
code is run -- that is, initialize the DRAM in lowlevel_init().

48
common/package/boot/uboot-ipq40xx/src/doc/README.mpc5xx Normal file
View file

@ -0,0 +1,48 @@
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/arch/powerpc/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/arch/powerpc/lib/board.c
u-boot-0.2.0/arch/powerpc/lib/cache.c
u-boot-0.2.0/arch/powerpc/lib/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

184
common/package/boot/uboot-ipq40xx/src/doc/README.mpc7448hpc2 Normal file
View file

@ -0,0 +1,184 @@
Freescale MPC7448hpc2 (Taiga) board
===================================
Created 08/11/2006 Roy Zang
--------------------------
MPC7448hpc2 (Taiga) board is a high-performance PowerPC server reference
design, which is optimized for high speed throughput between the processor and
the memory, disk drive and Ethernet port subsystems.
MPC7448hpc2(Taiga) is designed to the micro-ATX chassis, allowing it to be
used in 1U or 2U rack-mount chassis¡¯, as well as in standard ATX/Micro-ATX
chassis.
Building U-Boot
------------------
The mpc7448hpc2 code base is known to compile using:
Binutils 2.15, Gcc 3.4.3, Glibc 2.3.3
$ make mpc7448hpc2_config
Configuring for mpc7448hpc2 board...
$ make
Memory Map
----------
The memory map is setup for Linux to operate properly.
The mapping is:
Range Start Range End Definition Size
0x0000_0000 0x7fff_ffff DDR 2G
0xe000_0000 0xe7ff_ffff PCI Memory 128M
0xfa00_0000 0xfaff_ffff PCI IO 16M
0xfb00_0000 0xfbff_ffff PCI Config 16M
0xfc00_0000 0xfc0f_ffff NVRAM/CADMUS 1M
0xfe00_0000 0xfeff_ffff PromJet 16M
0xff00_0000 0xff80_0000 FLASH (boot flash) 8M
0xff80_0000 0xffff_ffff FLASH (second half flash) 8M
Using Flash
-----------
The MPC7448hpc2 board has two "banks" of flash, each 8MB in size
(2^23 = 0x00800000).
Note: the "bank" here refers to half of the flash. In fact, there is only one
bank of flash, which is divided into low and high half. Each is controlled by
the most significant bit of the address bus. The so called "bank" is only for
convenience.
There is a switch which allows the "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 ff800000 ff880000
cp.b ff000000 ff800000 80000
U-boot commands for downloading an image via tftp and flashing
it into the secondary bank:
tftp 10000 <u-boot.bin.image>
erase ff000000 ff080000
cp.b 10000 ff000000 80000
After copying the image into the second bank of flash, be sure to toggle
SW3[4] on board before resetting the board in order to set the
secondary bank as the boot-bank.
Board Switches
----------------------
Most switches on the board should not be changed. The most frequent
user-settable switches on the board are used to configure
the flash banks and determining the PCI frequency.
SW1[1-5]: Processor core voltage
12345 Core Voltage
-----
SW1=01111 1.000V.
SW1=01101 1.100V.
SW1=01011 1.200V.
SW1=01001 1.300V only for MPC7447A.
SW2[1-6]: CPU core frequency
CPU Core Frequency (MHz)
Bus Frequency
123456 100 133 167 200 Ratio
------
SW2=101100 500 667 833 1000 5x
SW2=100100 550 733 917 1100 5.5x
SW2=110100 600 800 1000 1200 6x
SW2=010100 650 866 1083 1300 6.5x
SW2=001000 700 930 1167 1400 7x
SW2=000100 750 1000 1250 1500 7.5x
SW2=110000 800 1066 1333 1600 8x
SW2=011000 850 1333 1417 1700 8.5x only for MPC7447A
SW2=011110 900 1200 1500 1800 9x
This table shows only a subset of available frequency options; see the CPU
hardware specifications for more information.
SW2[7-8]: Bus Protocol and CPU Reset Option
7
-
SW2=0 System bus uses MPX bus protocol
SW2=1 System bus uses 60x bus protocol
8
-
SW2=0 TSI108 can cause CPU reset
SW2=1 TSI108 can not cause CPU reset
SW3[1-8] system options
123
---
SW3=xxx Connected to GPIO[0:2] on TSI108
4
-
SW3=0 CPU boots from low half of flash
SW3=1 CPU boots from high half of flash
5
-
SW3=0 SATA and slot2 connected to PCI bus
SW3=1 Only slot1 connected to PCI bus
6
-
SW3=0 USB connected to PCI bus
SW3=1 USB disconnected from PCI bus
7
-
SW3=0 Flash is write protected
SW3=1 Flash is NOT write protected
8
-
SW3=0 CPU will boot from flash
SW3=1 CPU will boot from PromJet
SW4[1-3]: System bus frequency
Bus Frequency (MHz)
---
SW4=010 183
SW4=011 100
SW4=100 133
SW4=101 166 only for MPC7447A
SW4=110 200 only for MPC7448
others reserved
SW4[4-6]: DDR2 SDRAM frequency
Bus Frequency (MHz)
---
SW4=000 external clock
SW4=011 system clock
SW4=100 133
SW4=101 166
SW4=110 200
others reserved
SW4[7-8]: PCI/PCI-X frequency control
7
-
SW4=0 PCI/PCI-X bus operates normally
SW4=1 PCI bus forced to PCI-33 mode
8
-
SW4=0 PCI-X mode at 133 MHz allowed
SW4=1 PCI-X mode limited to 100 MHz

Some files were not shown because too many files have changed in this diff Show more