ASR_BASE
Change-Id: Icf3719cc0afe3eeb3edc7fa80a2eb5199ca9dda1
diff --git a/marvell/uboot/doc/DocBook/.gitignore b/marvell/uboot/doc/DocBook/.gitignore
new file mode 100644
index 0000000..90c1b11
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/.gitignore
@@ -0,0 +1,15 @@
+*/
+*.xml
+*.ps
+*.pdf
+*.html
+*.9.gz
+*.9
+*.aux
+*.dvi
+*.log
+*.out
+*.png
+*.gif
+media-indices.tmpl
+media-entities.tmpl
diff --git a/marvell/uboot/doc/DocBook/Makefile b/marvell/uboot/doc/DocBook/Makefile
new file mode 100644
index 0000000..29b79d7
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/Makefile
@@ -0,0 +1,229 @@
+###
+# This makefile is used to generate the kernel documentation,
+# primarily based on in-line comments in various source files.
+# See doc/kernel-doc-nano-HOWTO.txt for instruction in how
+# to document the SRC - and how to read it.
+# To add a new book the only step required is to add the book to the
+# list of DOCBOOKS.
+
+include $(TOPDIR)/config.mk
+
+DOCBOOKS := fs.xml linker_lists.xml stdio.xml
+
+###
+# The build process is as follows (targets):
+# (xmldocs) [by docproc]
+# file.tmpl --> file.xml +--> file.ps (psdocs) [by db2ps or xmlto]
+# +--> file.pdf (pdfdocs) [by db2pdf or xmlto]
+# +--> DIR=file (htmldocs) [by xmlto]
+# +--> man/ (mandocs) [by xmlto]
+
+
+# for PDF and PS output you can choose between xmlto and docbook-utils tools
+PDF_METHOD = $(prefer-db2x)
+PS_METHOD = $(prefer-db2x)
+
+
+###
+# The targets that may be used.
+PHONY += $(obj).depend xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
+
+BOOKS := $(addprefix $(OBJTREE)/doc/DocBook/,$(DOCBOOKS))
+xmldocs: $(BOOKS)
+sgmldocs: xmldocs
+
+PS := $(patsubst %.xml, %.ps, $(BOOKS))
+psdocs: $(PS)
+
+PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
+pdfdocs: $(PDF)
+
+HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
+htmldocs: $(HTML)
+ $(call build_main_index)
+ $(call build_images)
+ $(call install_media_images)
+
+MAN := $(patsubst %.xml, %.9, $(BOOKS))
+mandocs: $(MAN)
+
+installmandocs: mandocs
+ mkdir -p /usr/local/man/man9/
+ install doc/DocBook/man/*.9.gz /usr/local/man/man9/
+
+###
+#External programs used
+KERNELDOC = $(SRCTREE)/tools/kernel-doc/kernel-doc
+DOCPROC = $(OBJTREE)/tools/kernel-doc/docproc
+
+XMLTOFLAGS = -m $(SRCTREE)/doc/DocBook/stylesheet.xsl
+XMLTOFLAGS += --skip-validation
+
+###
+# DOCPROC is used for two purposes:
+# 1) To generate a dependency list for a .tmpl file
+# 2) To preprocess a .tmpl file and call kernel-doc with
+# appropriate parameters.
+# The following rules are used to generate the .xml documentation
+# required to generate the final targets. (ps, pdf, html).
+%.xml: %.tmpl
+ $(DOCPROC) doc $< >$@
+
+ifeq ($@, "cleandocs")
+sinclude $(obj).depend
+$(obj).depend: $(patsubst %.xml, %.tmpl, $(DOCBOOKS))
+ rm -f $(obj).depend ; \
+ touch $(obj).depend ; \
+ for file in $^ ; do \
+ xmlfile=`echo "$${file}" | \
+ sed "s/tmpl$$/xml/"` ; \
+ echo -n "$${xmlfile}: ">> $(obj).depend ; \
+ $(DOCPROC) depend $$file >> $(obj).depend ; \
+ echo -e "\n\t$(DOCPROC) doc $< >$${xmlfile} " >> \
+ $(obj).depend ; \
+ done
+endif
+
+###
+# Changes in kernel-doc force a rebuild of all documentation
+$(BOOKS): $(KERNELDOC)
+
+notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
+ exit 1
+db2xtemplate = db2TYPE -o $(dir $@) $<
+xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
+
+# determine which methods are available
+ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
+ use-db2x = db2x
+ prefer-db2x = db2x
+else
+ use-db2x = notfound
+ prefer-db2x = $(use-xmlto)
+endif
+ifeq ($(shell which xmlto >/dev/null 2>&1 && echo found),found)
+ use-xmlto = xmlto
+ prefer-xmlto = xmlto
+else
+ use-xmlto = notfound
+ prefer-xmlto = $(use-db2x)
+endif
+
+# the commands, generated from the chosen template
+quiet_cmd_db2ps = PS $@
+ cmd_db2ps = $(subst TYPE,ps, $($(PS_METHOD)template))
+%.ps : %.xml
+ $(call cmd_db2ps)
+
+quiet_cmd_db2pdf = PDF $@
+ cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
+%.pdf : %.xml
+ $(call cmd_db2pdf)
+
+
+index = index.html
+main_idx = $(index)
+build_main_index = rm -rf $(main_idx); \
+ echo '<h1>U-Boot Bootloader HTML Documentation</h1>' >> $(main_idx) && \
+ echo '<h2>U-Boot Version: $(U_BOOT_VERSION)</h2>' >> $(main_idx) && \
+ cat $(HTML) >> $(main_idx)
+
+# To work around bug [1] in docbook-xsl-stylesheets 1.76.1 , generate only html
+# docs instead of xhtml with xmlto.
+# [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654338
+quiet_cmd_db2html = HTML $@
+ cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
+ echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
+ $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+
+%.html: %.xml
+ @(which xmlto > /dev/null 2>&1) || \
+ (echo "*** You need to install xmlto ***"; \
+ exit 1)
+ @rm -rf $@ $(patsubst %.html,%,$@)
+ $(call cmd_db2html)
+ @if [ ! -z "$(PNG-$(basename $(notdir $@)))" ]; then \
+ cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
+
+quiet_cmd_db2man = MAN $@
+ cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
+%.9 : %.xml
+ @(which xmlto > /dev/null 2>&1) || \
+ (echo "*** You need to install xmlto ***"; \
+ exit 1)
+ $(Q)mkdir -p $(obj)man
+ $(call cmd_db2man)
+ @touch $@
+
+###
+# Rules to generate postscripts and PNG images from .fig format files
+quiet_cmd_fig2eps = FIG2EPS $@
+ cmd_fig2eps = fig2dev -Leps $< $@
+
+%.eps: %.fig
+ @(which fig2dev > /dev/null 2>&1) || \
+ (echo "*** You need to install transfig ***"; \
+ exit 1)
+ $(call cmd_fig2eps)
+
+quiet_cmd_fig2png = FIG2PNG $@
+ cmd_fig2png = fig2dev -Lpng $< $@
+
+%.png: %.fig
+ @(which fig2dev > /dev/null 2>&1) || \
+ (echo "*** You need to install transfig ***"; \
+ exit 1)
+ $(call cmd_fig2png)
+
+###
+# Rule to convert a .c file to inline XML documentation
+ gen_xml = :
+ quiet_gen_xml = echo ' GEN $@'
+silent_gen_xml = :
+%.xml: %.c
+ @$($(quiet)gen_xml)
+ @( \
+ echo "<programlisting>"; \
+ expand --tabs=8 < $< | \
+ sed -e "s/&/\\&/g" \
+ -e "s/</\\</g" \
+ -e "s/>/\\>/g"; \
+ echo "</programlisting>") > $@
+
+###
+# Help targets as used by the top-level makefile
+dochelp:
+ @echo ' U-Boot bootloader internal documentation in different formats:'
+ @echo ' htmldocs - HTML'
+ @echo ' pdfdocs - PDF'
+ @echo ' psdocs - Postscript'
+ @echo ' xmldocs - XML DocBook'
+ @echo ' mandocs - man pages'
+ @echo ' installmandocs - install man pages generated by mandocs'
+ @echo ' cleandocs - clean all generated DocBook files'
+
+###
+# Temporary files left by various tools
+clean-files := $(DOCBOOKS) \
+ $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.log, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.out, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.ps, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.html, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.9, $(DOCBOOKS)) \
+ $(index)
+
+clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
+
+cleandocs:
+ @rm -f $(obj).depend
+ @$(Q)rm -f $(call objectify, $(clean-files))
+ @$(Q)rm -rf $(call objectify, $(clean-dirs))
+
+# Declare the contents of the .PHONY variable as phony. We keep that
+# information in a variable se we can use it in if_changed and friends.
+
+.PHONY: $(PHONY)
diff --git a/marvell/uboot/doc/DocBook/docbook.css b/marvell/uboot/doc/DocBook/docbook.css
new file mode 100644
index 0000000..7a79ec5
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/docbook.css
@@ -0,0 +1,16 @@
+body {
+ font-family: sans-serif;
+}
+
+.programlisting {
+ font-family: monospace;
+ font-size: 1em;
+ display: block;
+ padding: 10px;
+ border: 1px solid #aaa;
+ color: #000;
+ background-color: #eee;
+ overflow: auto;
+ margin: 1em 0em;
+ border-radius: 6px;
+}
diff --git a/marvell/uboot/doc/DocBook/linker_lists.tmpl b/marvell/uboot/doc/DocBook/linker_lists.tmpl
new file mode 100644
index 0000000..f197516
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/linker_lists.tmpl
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+
+<book id="UBootLGArrays">
+ <bookinfo>
+ <title>The U-Boot Linker-Generated Arrays</title>
+
+ <legalnotice>
+ <para>
+ This documentation 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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
+ </para>
+
+ <para>
+ For more details see the file COPYING in the source
+ distribution of U-Boot Bootloader.
+ </para>
+ </legalnotice>
+ </bookinfo>
+
+<toc></toc>
+
+ <chapter id="adt">
+ <title>Linker-Generated Arrays</title>
+!Iinclude/linker_lists.h
+ </chapter>
+
+</book>
diff --git a/marvell/uboot/doc/DocBook/stdio.tmpl b/marvell/uboot/doc/DocBook/stdio.tmpl
new file mode 100644
index 0000000..4783abb
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/stdio.tmpl
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+
+<book id="UBootSTDIO">
+ <bookinfo>
+ <title>The U-Boot STDIO subsystem</title>
+
+ <legalnotice>
+ <para>
+ This documentation 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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
+ </para>
+
+ <para>
+ For more details see the file COPYING in the source
+ distribution of U-Boot Bootloader.
+ </para>
+ </legalnotice>
+ </bookinfo>
+
+<toc></toc>
+
+ <chapter id="adt">
+ <title>U-Boot Serial subsystem</title>
+!Idrivers/serial/serial.c
+ </chapter>
+
+</book>
diff --git a/marvell/uboot/doc/DocBook/stylesheet.xsl b/marvell/uboot/doc/DocBook/stylesheet.xsl
new file mode 100644
index 0000000..8adce56
--- /dev/null
+++ b/marvell/uboot/doc/DocBook/stylesheet.xsl
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<param name="chunk.quietly">1</param>
+<param name="funcsynopsis.style">ansi</param>
+<param name="funcsynopsis.tabular.threshold">80</param>
+<param name="callout.graphics">0</param>
+<!-- <param name="paper.type">A4</param> -->
+<param name="generate.section.toc.level">2</param>
+<param name="use.id.as.filename">1</param>
+<param name="html.stylesheet">../docbook.css</param>
+</stylesheet>
diff --git a/marvell/uboot/doc/I2C_Edge_Conditions b/marvell/uboot/doc/I2C_Edge_Conditions
new file mode 100644
index 0000000..f4a9968
--- /dev/null
+++ b/marvell/uboot/doc/I2C_Edge_Conditions
@@ -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)
diff --git a/marvell/uboot/doc/README.440-DDR-performance b/marvell/uboot/doc/README.440-DDR-performance
new file mode 100644
index 0000000..17bc747
--- /dev/null
+++ b/marvell/uboot/doc/README.440-DDR-performance
@@ -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>
diff --git a/marvell/uboot/doc/README.AMCC-eval-boards-cleanup b/marvell/uboot/doc/README.AMCC-eval-boards-cleanup
new file mode 100644
index 0000000..901bd87
--- /dev/null
+++ b/marvell/uboot/doc/README.AMCC-eval-boards-cleanup
@@ -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>
diff --git a/marvell/uboot/doc/README.ARM-SoC b/marvell/uboot/doc/README.ARM-SoC
new file mode 100644
index 0000000..d6bd624
--- /dev/null
+++ b/marvell/uboot/doc/README.ARM-SoC
@@ -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
diff --git a/marvell/uboot/doc/README.ARM-memory-map b/marvell/uboot/doc/README.ARM-memory-map
new file mode 100644
index 0000000..1b120ac
--- /dev/null
+++ b/marvell/uboot/doc/README.ARM-memory-map
@@ -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.
diff --git a/marvell/uboot/doc/README.AVR32 b/marvell/uboot/doc/README.AVR32
new file mode 100644
index 0000000..632cc05
--- /dev/null
+++ b/marvell/uboot/doc/README.AVR32
@@ -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.
diff --git a/marvell/uboot/doc/README.AVR32-port-muxing b/marvell/uboot/doc/README.AVR32-port-muxing
new file mode 100644
index 0000000..8c1718c
--- /dev/null
+++ b/marvell/uboot/doc/README.AVR32-port-muxing
@@ -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.
diff --git a/marvell/uboot/doc/README.JFFS2 b/marvell/uboot/doc/README.JFFS2
new file mode 100644
index 0000000..f0e9bc1
--- /dev/null
+++ b/marvell/uboot/doc/README.JFFS2
@@ -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 ∂
+
+ 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 ∂
+ }
+ 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).
diff --git a/marvell/uboot/doc/README.JFFS2_NAND b/marvell/uboot/doc/README.JFFS2_NAND
new file mode 100644
index 0000000..09788d5
--- /dev/null
+++ b/marvell/uboot/doc/README.JFFS2_NAND
@@ -0,0 +1,24 @@
+JFFS2 NAND support:
+
+To enable, 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.
diff --git a/marvell/uboot/doc/README.LED b/marvell/uboot/doc/README.LED
new file mode 100644
index 0000000..c3bcb3a
--- /dev/null
+++ b/marvell/uboot/doc/README.LED
@@ -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
diff --git a/marvell/uboot/doc/README.LED_display b/marvell/uboot/doc/README.LED_display
new file mode 100644
index 0000000..19977ea
--- /dev/null
+++ b/marvell/uboot/doc/README.LED_display
@@ -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).
diff --git a/marvell/uboot/doc/README.MPC866 b/marvell/uboot/doc/README.MPC866
new file mode 100644
index 0000000..4707cb7
--- /dev/null
+++ b/marvell/uboot/doc/README.MPC866
@@ -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.
diff --git a/marvell/uboot/doc/README.Modem b/marvell/uboot/doc/README.Modem
new file mode 100644
index 0000000..1613c11
--- /dev/null
+++ b/marvell/uboot/doc/README.Modem
@@ -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
diff --git a/marvell/uboot/doc/README.N1213 b/marvell/uboot/doc/README.N1213
new file mode 100644
index 0000000..e107166
--- /dev/null
+++ b/marvell/uboot/doc/README.N1213
@@ -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.
diff --git a/marvell/uboot/doc/README.NDS32 b/marvell/uboot/doc/README.NDS32
new file mode 100644
index 0000000..b2b58fc
--- /dev/null
+++ b/marvell/uboot/doc/README.NDS32
@@ -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.
diff --git a/marvell/uboot/doc/README.NetConsole b/marvell/uboot/doc/README.NetConsole
new file mode 100644
index 0000000..af7fc60
--- /dev/null
+++ b/marvell/uboot/doc/README.NetConsole
@@ -0,0 +1,97 @@
+
+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.
+
+CONFIG_NETCONSOLE_BUFFER_SIZE - Override the default buffer size
+
+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.
+The source / listening port can be configured separately by setting
+the 'ncinport' environment variable and the destination port can be
+configured by setting the 'ncoutport' environment variable.
+
+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.
diff --git a/marvell/uboot/doc/README.OFT b/marvell/uboot/doc/README.OFT
new file mode 100644
index 0000000..dd1c632
--- /dev/null
+++ b/marvell/uboot/doc/README.OFT
@@ -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
diff --git a/marvell/uboot/doc/README.POST b/marvell/uboot/doc/README.POST
new file mode 100644
index 0000000..6815d49
--- /dev/null
+++ b/marvell/uboot/doc/README.POST
@@ -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
diff --git a/marvell/uboot/doc/README.SNTP b/marvell/uboot/doc/README.SNTP
new file mode 100644
index 0000000..da9ec45
--- /dev/null
+++ b/marvell/uboot/doc/README.SNTP
@@ -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.
diff --git a/marvell/uboot/doc/README.SPL b/marvell/uboot/doc/README.SPL
new file mode 100644
index 0000000..312a6a6
--- /dev/null
+++ b/marvell/uboot/doc/README.SPL
@@ -0,0 +1,111 @@
+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)
+CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
+CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
+
+Normally CPU is assumed to be the same between the SPL and normal
+u-boot build. However it is possible to specify a different CPU for
+the SPL build for cases where the SPL is expected to run on a
+different CPU model from the main u-boot. This is done by specifying
+an SPL CPU in boards.cfg as follows:
+
+ normal_cpu:spl_cpu
+
+This case CPU will be set to "normal_cpu" during the main u-boot
+build and "spl_cpu" during the SPL build.
+
+
+Debugging
+---------
+
+When building SPL with DEBUG set you may also need to set CONFIG_PANIC_HANG
+as in most cases do_reset is not defined within SPL.
+
+
+Estimating stack usage
+----------------------
+
+With gcc 4.6 (and later) and the use of GNU cflow it is possible to estimate
+stack usage at various points in run sequence of SPL. The -fstack-usage option
+to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that
+will give stack usage information and cflow can construct program flow.
+
+Must have gcc 4.6 or later, which supports -fstack-usage
+
+1) Build normally
+2) Perform the following shell command to generate a list of C files used in
+SPL:
+$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list
+3) Execute cflow:
+$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER
+
+cflow will spit out a number of warnings as it does not parse
+the config files and picks functions based on #ifdef. Parsing the '.i'
+files instead introduces another set of headaches. These warnings are
+not usually important to understanding the flow, however.
diff --git a/marvell/uboot/doc/README.TPL b/marvell/uboot/doc/README.TPL
new file mode 100644
index 0000000..1df03b9
--- /dev/null
+++ b/marvell/uboot/doc/README.TPL
@@ -0,0 +1,45 @@
+Generic TPL framework
+=====================
+
+Overview
+--------
+
+TPL---Third Program Loader.
+
+Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot
+be compatible with all the external device(e.g. DDR). So add a tertiary
+program loader (TPL) to enable a loader stub loaded by the code from the
+SPL. It loads the final uboot image into DDR, then jump to it to begin
+execution. Now, only the powerpc mpc85xx has this requirement and will
+implemente it.
+
+Keep consistent with SPL, 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 has been a directory TOPDIR/spl which contains only a Makefile. The
+Makefile is shared by SPL and TPL.
+
+The object files are built separately for SPL/TPL and placed in the
+directory spl/tpl. The final binaries which are generated are
+u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map.
+
+During the TPL build a variable named CONFIG_TPL_BUILD is exported in the
+make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD.
+
+The SPL options are shared by SPL and TPL, the board config file should
+determine which SPL options to choose based on whether CONFIG_TPL_BUILD
+is set. Source files can be compiled for TPL with options choosed in the
+board config file.
+
+For example:
+
+spl/Makefile:
+LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o
+
+CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file:
+#ifdef CONFIG_TPL_BUILD
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#endif
diff --git a/marvell/uboot/doc/README.VLAN b/marvell/uboot/doc/README.VLAN
new file mode 100644
index 0000000..4f86d55
--- /dev/null
+++ b/marvell/uboot/doc/README.VLAN
@@ -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.
diff --git a/marvell/uboot/doc/README.VSC3316-3308 b/marvell/uboot/doc/README.VSC3316-3308
new file mode 100644
index 0000000..925663b
--- /dev/null
+++ b/marvell/uboot/doc/README.VSC3316-3308
@@ -0,0 +1,43 @@
+This file contains API information of the initialization code written for
+Vitesse cross-point devices, VSC3316 and VSC3308 for board B4860QDS
+
+Author: Shaveta Leekha <shaveta@freescale.com>
+
+About Device:
+=============
+VSC 3316/3308 is a low-power, low-cost asynchronous crosspoint switch capable of data rates upto 11.5Gbps.
+
+VSC3316 has 16 input and 16 output ports whereas VSC3308 has 8 input and 8 output ports. Programming of these devices are performed by two-wire or four-wire serial interface.
+
+Initialization:
+===============
+On reset, VSC devices are in low-power state with all inputs, outputs and connections in an off state.
+First thing required is to program it to interface with either two-wire or four-wire interface.
+In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. Also for crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register).
+
+API Overview:
+=============
+
+ vsc_if_enable(u8 vsc_addr):
+ --------------------------
+ This API programs VSC to interface with either two-wire or four-wire interface. In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface.
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
+
+
+ vsc3316_config(u8 vsc_addr, int con_arr[][2], u8 num_con):
+ ---------------------------------------------------------
+ This API configures the VSC3316 device for required connections. Connection through the VSC device requires the inputs and outputs to be properly configured.
+ Connection registers are on page 00. It Configures the selected input and output correctly and join them to make a connection. It also program Input state register, Global input ISE, Global input LOS, Global core control, Output mode register and core control registers etc.
+ vsc3308_config(u8 vsc_addr, int con_arr[][2], u8 num_con) does the essential configurations for VSC3308.
+
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
+ con_arr - connection array
+ num_con - number of connections to be configured
+
+ vsc_wp_config(u8 vsc_addr):
+ --------------------------
+ For crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register), which is done by this API.
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
diff --git a/marvell/uboot/doc/README.ag102 b/marvell/uboot/doc/README.ag102
new file mode 100644
index 0000000..7d142a7
--- /dev/null
+++ b/marvell/uboot/doc/README.ag102
@@ -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.
diff --git a/marvell/uboot/doc/README.arm-caches b/marvell/uboot/doc/README.arm-caches
new file mode 100644
index 0000000..f6a52e3
--- /dev/null
+++ b/marvell/uboot/doc/README.arm-caches
@@ -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.
diff --git a/marvell/uboot/doc/README.arm-relocation b/marvell/uboot/doc/README.arm-relocation
new file mode 100644
index 0000000..645b374
--- /dev/null
+++ b/marvell/uboot/doc/README.arm-relocation
@@ -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 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 booting from NAND Flash:
+
+a) cpu starts
+b) it copies the first page in nand to internal ram
+ (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 SPL (example for the tx25 booting from NAND Flash):
+
+- 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 drivers/mtd/nand/mxc_nand_spl.c
+ which inits the dram, cpu registers, reloacte itself to CONFIG_SPL_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_SPL_TEXT_BASE from the 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 :-)
diff --git a/marvell/uboot/doc/README.arm-unaligned-accesses b/marvell/uboot/doc/README.arm-unaligned-accesses
new file mode 100644
index 0000000..c37d135
--- /dev/null
+++ b/marvell/uboot/doc/README.arm-unaligned-accesses
@@ -0,0 +1,122 @@
+If you are reading this because of a data abort: the following MIGHT
+be relevant to your abort, if it was caused by an alignment violation.
+In order to determine this, use the PC from the abort dump along with
+an objdump -s -S of the u-boot ELF binary to locate the function where
+the abort happened; then compare this function with the examples below.
+If they match, then you've been hit with a compiler generated unaligned
+access, and you should rewrite your code or add -mno-unaligned-access
+to the command line of the offending file.
+
+Note that the PC shown in the abort message is relocated. In order to
+be able to match it to an address in the ELF binary dump, you will need
+to know the relocation offset. If your target defines CONFIG_CMD_BDI
+and if you can get to the prompt and enter commands before the abort
+happens, then command "bdinfo" will give you the offset. Otherwise you
+will need to try a build with DEBUG set, which will display the offset,
+or use a debugger and set a breakpoint at relocate_code() to see the
+offset (passed as an argument).
+
+*
+
+Since U-Boot runs on a variety of hardware, some only able to perform
+unaligned accesses with a strong penalty, some unable to perform them
+at all, the policy regarding unaligned accesses is to not perform any,
+unless absolutely necessary because of hardware or standards.
+
+Also, on hardware which permits it, the core is configured to throw
+data abort exceptions on unaligned accesses in order to catch these
+unallowed accesses as early as possible.
+
+Until version 4.7, the gcc default for performing unaligned accesses
+(-mno-unaligned-access) is to emulate unaligned accesses using aligned
+loads and stores plus shifts and masks. Emulated unaligned accesses
+will not be caught by hardware. These accesses may be costly and may
+be actually unnecessary. In order to catch these accesses and remove
+or optimize them, option -munaligned-access is explicitly set for all
+versions of gcc which support it.
+
+From gcc 4.7 onward starting at armv7 architectures, the default for
+performing unaligned accesses is to use unaligned native loads and
+stores (-munaligned-access), because the cost of unaligned accesses
+has dropped on armv7 and beyond. This should not affect U-Boot's
+policy of controlling unaligned accesses, however the compiler may
+generate uncontrolled unaligned accesses on its own in at least one
+known case: when declaring a local initialized char array, e.g.
+
+function foo()
+{
+ char buffer[] = "initial value";
+/* or */
+ char buffer[] = { 'i', 'n', 'i', 't', 0 };
+ ...
+}
+
+Under -munaligned-accesses with optimizations on, this declaration
+causes the compiler to generate native loads from the literal string
+and native stores to the buffer, and the literal string alignment
+cannot be controlled. If it is misaligned, then the core will throw
+a data abort exception.
+
+Quite probably the same might happen for 16-bit array initializations
+where the constant is aligned on a boundary which is a multiple of 2
+but not of 4:
+
+function foo()
+{
+ u16 buffer[] = { 1, 2, 3 };
+ ...
+}
+
+The long term solution to this issue is to add an option to gcc to
+allow controlling the general alignment of data, including constant
+initialization values.
+
+However this will only apply to the version of gcc which will have such
+an option. For other versions, there are four workarounds:
+
+a) Enforce as a rule that array initializations as described above
+ are forbidden. This is generally not acceptable as they are valid,
+ and usual, C constructs. The only case where they could be rejected
+ is when they actually equate to a const char* declaration, i.e. the
+ array is initialized and never modified in the function's scope.
+
+b) Drop the requirement on unaligned accesses at least for ARMv7,
+ i.e. do not throw a data abort exception upon unaligned accesses.
+ But that will allow adding badly aligned code to U-Boot, only for
+ it to fail when re-used with a stricter target, possibly once the
+ bad code is already in mainline.
+
+c) Relax the -munaligned-access rule globally. This will prevent native
+ unaligned accesses of course, but that will also hide any bug caused
+ by a bad unaligned access, making it much harder to diagnose it. It
+ is actually what already happens when building ARM targets with a
+ pre-4.7 gcc, and it may actually already hide some bugs yet unseen
+ until the target gets compiled with -munaligned-access.
+
+d) Relax the -munaligned-access rule only for for files susceptible to
+ the local initialized array issue and for armv7 architectures and
+ beyond. This minimizes the quantity of code which can hide unwanted
+ misaligned accesses.
+
+The option retained is d).
+
+Considering that actual occurrences of the issue are rare (as of this
+writing, 5 files out of 7840 in U-Boot, or .3%, contain an initialized
+local char array which cannot actually be replaced with a const char*),
+contributors should not be required to systematically try and detect
+the issue in their patches.
+
+Detecting files susceptible to the issue can be automated through a
+filter installed as a hook in .git which recognizes local char array
+initializations. Automation should err on the false positive side, for
+instance flagging non-local arrays as if they were local if they cannot
+be told apart.
+
+In any case, detection shall not prevent committing the patch, but
+shall pre-populate the commit message with a note to the effect that
+this patch contains an initialized local char or 16-bit array and thus
+should be protected from the gcc 4.7 issue.
+
+Upon a positive detection, either $(PLATFORM_NO_UNALIGNED) should be
+added to CFLAGS for the affected file(s), or if the array is a pseudo
+const char*, it should be replaced by an actual one.
diff --git a/marvell/uboot/doc/README.arm64 b/marvell/uboot/doc/README.arm64
new file mode 100644
index 0000000..75586db
--- /dev/null
+++ b/marvell/uboot/doc/README.arm64
@@ -0,0 +1,46 @@
+U-boot for arm64
+
+Summary
+=======
+No hardware platform of arm64 is available now. The u-boot is
+simulated on Foundation Model and Fast Model for ARMv8.
+
+Notes
+=====
+
+1. Currenly, u-boot run at the highest exception level processor
+ supported and jump to EL2 or optionally EL1 before enter OS.
+
+2. U-boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
+ use rela relocation format, a tool(tools/relocate-rela) by Scott Wood
+ is used to encode the initial addend of rela to u-boot.bin. After running,
+ the u-boot will be relocated to destination again.
+
+3. Fdt should be placed at a 2-megabyte boundary and within the first 512
+ megabytes from the start of the kernel image. So, fdt_high should be
+ defined specially.
+ Please reference linux/Documentation/arm64/booting.txt for detail.
+
+4. Spin-table is used to wake up secondary processors. One location
+ (or per processor location) is defined to hold the kernel entry point
+ for secondary processors. It must be ensured that the location is
+ accessible and zero immediately after secondary processor
+ enter slave_cpu branch execution in start.S. The location address
+ is encoded in cpu node of DTS. Linux kernel store the entry point
+ of secondary processors to it and send event to wakeup secondary
+ processors.
+ Please reference linux/Documentation/arm64/booting.txt for detail.
+
+5. Generic board is supported.
+
+6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and
+ aarch32 specific codes.
+
+Contributor
+===========
+ Tom Rini <trini@ti.com>
+ Scott Wood <scottwood@freescale.com>
+ York Sun <yorksun@freescale.com>
+ Simon Glass <sjg@chromium.org>
+ Sharma Bhupesh <bhupesh.sharma@freescale.com>
+ Rob Herring <robherring2@gmail.com>
diff --git a/marvell/uboot/doc/README.at91 b/marvell/uboot/doc/README.at91
new file mode 100644
index 0000000..6741213
--- /dev/null
+++ b/marvell/uboot/doc/README.at91
@@ -0,0 +1,174 @@
+Atmel AT91 Evaluation kits
+
+Index
+ - I. Board mapping & boot media
+ - II. NAND partition table
+ - III. watchdog support
+
+I. Board mapping & boot media
+------------------------------------------------------------------------------
+AT91SAM9260EK, AT91SAM9G20EK & AT91SAM9XEEK
+------------------------------------------------------------------------------
+
+Memory map
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - Cxxxxxxx Atmel Dataflash card (J13)
+ 0xD0000000 - D07FFFFF Soldered Atmel Dataflash (AT45DB642)
+
+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_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 - C07FFFFF Soldered Atmel Dataflash (AT45DB642)
+ 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_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_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
+ 0x70000000 - 77FFFFFF SDRAM (128 MB)
+
+Environment variables
+
+ U-Boot environment variables can be stored at different places:
+ - Nand flash.
+
+ You can choose your storage location at config step (here for at91sam9m10g45ek) :
+ make at91sam9m10g45ek_nandflash_config - use nand flash
+
+
+------------------------------------------------------------------------------
+AT91SAM9RLEK
+------------------------------------------------------------------------------
+
+Memory map
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - C07FFFFF Soldered Atmel Dataflash (AT45DB642)
+
+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 at91sam9rlek) :
+ make at91sam9rlek_nandflash_config - use nand flash
+
+
+------------------------------------------------------------------------------
+AT91SAM9N12EK, AT91SAM9X5EK
+------------------------------------------------------------------------------
+
+Memory map
+ 0x20000000 - 27FFFFFF SDRAM (128 MB)
+
+Environment variables
+
+ U-Boot environment variables can be stored at different places:
+ - Nand flash.
+ - SD/MMC card
+ - Serialflash/Dataflash on SPI chip select 0
+
+ You can choose your storage location at config step (here for at91sam9x5ek) :
+ make at91sam9x5ek_dataflash_config - use data flash
+ make at91sam9x5ek_mmc_config - use sd/mmc card
+ make at91sam9x5ek_nandflash_config - use nand flash
+ make at91sam9x5ek_spiflash_config - use serial flash
+
+
+------------------------------------------------------------------------------
+SAMA5D3XEK
+------------------------------------------------------------------------------
+
+Memory map
+ 0x20000000 - 3FFFFFFF SDRAM (512 MB)
+
+Environment variables
+
+ U-Boot environment variables can be stored at different places:
+ - Nand flash.
+ - SD/MMC card
+ - Serialflash on SPI chip select 0
+
+ You can choose your storage location at config step (here for sama5d3xek) :
+ make sama5d3xek_mmc_config - use SD/MMC card
+ make sama5d3xek_nandflash_config - use nand flash
+ make sama5d3xek_serialflash_config - use serial flash
+
+
+II. NAND partition table
+
+ All the board support boot from NAND flash will use the following NAND
+ partition table
+
+ 0x00000000 - 0x0003FFFF bootstrap (256 KiB)
+ 0x00040000 - 0x000BFFFF u-boot (512 KiB)
+ 0x000C0000 - 0x000FFFFF env (256 KiB)
+ 0x00100000 - 0x0013FFFF env_redundant (256 KiB)
+ 0x00140000 - 0x0017FFFF spare (256 KiB)
+ 0x00180000 - 0x001FFFFF dtb (512 KiB)
+ 0x00200000 - 0x007FFFFF kernel (6 MiB)
+ 0x00800000 - 0xxxxxxxxx rootfs (All left)
+
+III. 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.
diff --git a/marvell/uboot/doc/README.at91-soc b/marvell/uboot/doc/README.at91-soc
new file mode 100644
index 0000000..ab3f713
--- /dev/null
+++ b/marvell/uboot/doc/README.at91-soc
@@ -0,0 +1,48 @@
+ 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
+
+2013-10-30 Andreas Bießmann <andreas.devel@googlemail.com>:
+
+The goal is almost reached, we could remove the CONFIG_AT91_LEGACY switch but
+remain the CONFIG_ATMEL_LEGACY switch until the GPIO disaster is fixed. The
+AT91 spi driver has also some CONFIG_ATMEL_LEGACY stuff left, so another point
+to fix until this README can be removed.
diff --git a/marvell/uboot/doc/README.atmel_mci b/marvell/uboot/doc/README.atmel_mci
new file mode 100644
index 0000000..1ec4465
--- /dev/null
+++ b/marvell/uboot/doc/README.atmel_mci
@@ -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
diff --git a/marvell/uboot/doc/README.atmel_pmecc b/marvell/uboot/doc/README.atmel_pmecc
new file mode 100644
index 0000000..cf8373b
--- /dev/null
+++ b/marvell/uboot/doc/README.atmel_pmecc
@@ -0,0 +1,29 @@
+How to enable PMECC(Programmable Multibit ECC) for nand on Atmel SoCs
+-----------------------------------------------------------
+2012-08-22 Josh Wu <josh.wu@atmel.com>
+
+The Programmable Multibit ECC (PMECC) controller is a programmable binary
+BCH(Bose, Chaudhuri and Hocquenghem) encoder and decoder. This controller
+can be used to support both SLC and MLC NAND Flash devices. It supports to
+generate ECC to correct 2, 4, 8, 12 or 24 bits of error per sector (512 or
+1024 bytes) of data.
+
+Following Atmel AT91 products support PMECC.
+- AT91SAM9X25, X35, G25, G15, G35 (tested)
+- AT91SAM9N12 (not tested, Should work)
+
+As soon as your nand flash software ECC works, you can enable PMECC.
+
+To use PMECC in this driver, the user needs to set:
+ 1. the PMECC correction error bits capability: CONFIG_PMECC_CAP.
+ It can be 2, 4, 8, 12 or 24.
+ 2. The PMECC sector size: CONFIG_PMECC_SECTOR_SIZE.
+ It only can be 512 or 1024.
+
+Take AT91SAM9X5EK as an example, the board definition file likes:
+
+/* PMECC & PMERRLOC */
+#define CONFIG_ATMEL_NAND_HWECC 1
+#define CONFIG_ATMEL_NAND_HW_PMECC 1
+#define CONFIG_PMECC_CAP 2
+#define CONFIG_PMECC_SECTOR_SIZE 512
diff --git a/marvell/uboot/doc/README.autoboot b/marvell/uboot/doc/README.autoboot
new file mode 100644
index 0000000..14e3660
--- /dev/null
+++ b/marvell/uboot/doc/README.autoboot
@@ -0,0 +1,157 @@
+/*
+ * (C) Copyright 2001
+ * Dave Ellis, SIXNET, dge@sixnetio.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+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_KEYED_CTRLC
+ 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).
+
+ The CONFIG_AUTOBOOT_KEYED_CTRLC #define allows for the boot
+ sequence to be interrupted by ctrl-c, in addition to the
+ "bootdelaykey" and "bootstopkey". Setting this variable
+ provides an escape sequence from the limited "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.
diff --git a/marvell/uboot/doc/README.b4860qds b/marvell/uboot/doc/README.b4860qds
new file mode 100644
index 0000000..48ece4b
--- /dev/null
+++ b/marvell/uboot/doc/README.b4860qds
@@ -0,0 +1,330 @@
+Overview
+--------
+The B4860QDS is a Freescale reference board that hosts the B4860 SoC (and variants).
+
+B4860 Overview
+-------------
+The B4860 QorIQ Qonverge device is a Freescale high-end, multicore SoC based on
+StarCore and Power Architecture® cores. It targets the broadband wireless
+infrastructure and builds upon the proven success of the existing multicore
+DSPs and Power CPUs. It is designed to bolster the rapidly changing and
+expanding wireless markets, such as 3GLTE (FDD and TDD), LTE-Advanced, and UMTS.
+
+The B4860 is a highly-integrated StarCore and Power Architecture processor that
+contains:
+. Six fully-programmable StarCore SC3900 FVP subsystems, divided into three
+clusters-each core runs up to 1.2 GHz, with an architecture highly optimized for
+wireless base station applications
+. Four dual-thread e6500 Power Architecture processors organized in one cluster-each
+core runs up to 1.8 GHz
+. Two DDR3/3L controllers for high-speed, industry-standard memory interface each
+runs at up to 1866.67 MHz
+. MAPLE-B3 hardware acceleration-for forward error correction schemes including
+Turbo or Viterbi decoding, Turbo encoding and rate matching, MIMO MMSE
+equalization scheme, matrix operations, CRC insertion and check, DFT/iDFT and
+FFT/iFFT calculations, PUSCH/PDSCH acceleration, and UMTS chip rate
+acceleration
+. CoreNet fabric that fully supports coherency using MESI protocol between the
+ e6500 cores, SC3900 FVP cores, memories and external interfaces.
+ CoreNet fabric interconnect runs at 667 MHz and supports coherent and
+ non-coherent out of order transactions with prioritization and bandwidth
+ allocation amongst CoreNet endpoints.
+. Data Path Acceleration Architecture, which includes the following:
+. Frame Manager (FMan), which supports in-line packet parsing and general
+ classification to enable policing and QoS-based packet distribution
+. Queue Manager (QMan) and Buffer Manager (BMan), which allow offloading
+ of queue management, task management, load distribution, flow ordering, buffer
+ management, and allocation tasks from the cores
+. Security engine (SEC 5.3)-crypto-acceleration for protocols such as IPsec,
+ SSL, and 802.16
+. RapidIO manager (RMAN) - Support SRIO types 8, 9, 10, and 11 (inbound and
+ outbound). Supports types 5, 6 (outbound only)
+. Large internal cache memory with snooping and stashing capabilities for
+ bandwidth saving and high utilization of processor elements. The 9856-Kbyte
+ internal memory space includes the following:
+. 32 Kbyte L1 ICache per e6500/SC3900 core
+. 32 Kbyte L1 DCache per e6500/SC3900 core
+. 2048 Kbyte unified L2 cache for each SC3900 FVP cluster
+. 2048 Kbyte unified L2 cache for the e6500 cluster
+. Two 512 Kbyte shared L3 CoreNet platform caches (CPC)
+. Sixteen 10-GHz SerDes lanes serving:
+. Two Serial RapidIO interfaces.
+ - Each supports up to 4 lanes and a total of up to 8 lanes
+. Up to 8-lanes Common Public Radio Interface (CPRI) controller for glue-less
+ antenna connection
+. Two 10-Gbit Ethernet controllers (10GEC)
+. Six 1G/2.5-Gbit Ethernet controllers for network communications
+. PCI Express controller
+. Debug (Aurora)
+. Two OCeaN DMAs
+. Various system peripherals
+. 182 32-bit timers
+
+B4860QDS Overview
+------------------
+- DDRC1: Ten separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 4 GB
+ of memory in two ranks of 2 GB.
+- DDRC2: Five separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 2 GB
+ of memory. Single rank.
+- SerDes 1 multiplexing: Two Vitesse (transmit and receive path) cross-point 16x16 switch
+ VSC3316
+- SerDes 2 multiplexing: Two Vitesse (transmit and receive path) cross-point 8x8 switch VSC3308
+- USB 2.0 ULPI PHY USB3315 by SMSC supports USB port in host mode.
+ B4860 UART port is available over USB-to-UART translator USB2SER or over RS232 flat cable.
+- A Vitesse dual SGMII phy VSC8662 links the B4860 SGMII lines to 2xRJ-45 copper connectors
+ for Stand-alone mode and to the 1000Base-X over AMC MicroTCA connector ports 0 and 2 for
+ AMC mode.
+- The B4860 configuration may be loaded from nine bits coded reset configuration reset source. The
+ RCW source is set by appropriate DIP-switches:
+- 16-bit NOR Flash / PROMJet
+- QIXIS 8-bit NOR Flash Emulator
+- 8-bit NAND Flash
+- 24-bit SPI Flash
+- Long address I2C EEPROM
+- Available debug interfaces are:
+ - On-board eCWTAP controller with ETH and USB I/F
+ - JTAG/COP 16-pin header for any external TAP controller
+ - External JTAG source over AMC to support B2B configuration
+ - 70-pin Aurora debug connector
+- QIXIS (FPGA) logic:
+ - 2 KB internal memory space including
+- IDT840NT4 clock synthesizer provides B4860 essential clocks : SYSCLK, DDRCLK1,2 and
+ RTCCLK.
+- Two 8T49N222A SerDes ref clock devices support two SerDes port clock frequency - total four
+ refclk, including CPRI clock scheme.
+
+B4420 Personality
+--------------------
+
+B4420 Personality
+--------------------
+B4420 is a reduced personality of B4860 with less core/clusters(both SC3900 and e6500), less DDR
+controllers, less serdes lanes, less SGMII interfaces and reduced target frequencies.
+
+Key differences between B4860 and B4420
+----------------------------------------
+
+B4420 has:
+1. Less e6500 cores: 1 cluster with 2 e6500 cores
+2. Less SC3900 cores/clusters: 1 cluster with 2 SC3900 cores per cluster.
+3. Single DDRC
+4. 2X 4 lane serdes
+5. 3 SGMII interfaces
+6. no sRIO
+7. no 10G
+
+B4860QDS Default Settings
+-------------------------
+
+Switch Settings
+----------------
+
+SW1 OFF [0] OFF [1] OFF [1] OFF [0] OFF [1] OFF [0] OFF [1] OFF [1]
+SW2 ON ON ON ON ON ON OFF OFF
+SW3 OFF OFF OFF ON OFF OFF ON OFF
+SW5 OFF OFF OFF OFF OFF OFF ON ON
+
+Note: PCIe slots modes: All the PCIe devices work as Root Complex.
+Note: Boot location: NOR flash.
+
+SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple
+66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz
+
+a) NAND boot
+ SW1 [1.1] = 0
+ SW2 [1.1] = 1
+ SW3 [1:4] = 0001
+b) NOR boot
+ SW1 [1.1] = 1
+ SW2 [1.1] = 0
+ SW3 [1:4] = 1000.
+
+B4420QDS Default Settings
+-------------------------
+
+Switch Settings
+----------------
+SW1 OFF[0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0]
+SW2 ON OFF ON OFF ON ON OFF OFF
+SW3 OFF OFF OFF ON OFF OFF ON OFF
+SW5 OFF OFF OFF OFF OFF OFF ON ON
+
+Note: PCIe slots modes: All the PCIe devices work as Root Complex.
+Note: Boot location: NOR flash.
+
+SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple
+66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz
+
+a) NAND boot
+ SW1 [1.1] = 0
+ SW2 [1.1] = 1
+ SW3 [1:4] = 0001
+b) NOR boot
+ SW1 [1.1] = 1
+ SW2 [1.1] = 0
+ SW3 [1:4] = 1000.
+
+Memory map on B4860QDS
+----------------------
+The addresses in brackets are physical addresses.
+
+Start Address End Address Description Size
+0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB
+0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB
+0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB
+0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB
+0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB
+0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB
+0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB
+0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB
+0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB
+0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB
+0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB
+0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB
+0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB
+0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB
+0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB
+0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB
+0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB
+0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB
+0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB
+0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB
+0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB
+0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB
+0x0_8000_0000 0x0_FFFF_FFFF DDRC1 2 GB
+0x0_0000_0000 0x0_7FFF_FFFF DDRC2 2 GB
+
+Memory map on B4420QDS
+----------------------
+The addresses in brackets are physical addresses.
+
+Start Address End Address Description Size
+0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB
+0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB
+0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB
+0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB
+0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB
+0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB
+0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB
+0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB
+0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB
+0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB
+0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB
+0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB
+0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB
+0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB
+0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB
+0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB
+0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB
+0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB
+0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB
+0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB
+0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB
+0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB
+0x0_0000_0000 0x0_FFFF_FFFF DDRC1 4 GB
+
+
+NOR Flash memory Map on B4860 and B4420QDS
+------------------------------------------
+ Start End Definition Size
+0xEFF80000 0xEFFFFFFF u-boot (current bank) 512KB
+0xEFF60000 0xEFF7FFFF u-boot env (current bank) 128KB
+0xEFF40000 0xEFF5FFFF FMAN Ucode (current bank) 128KB
+0xEF300000 0xEFF3FFFF rootfs (alternate bank) 12MB + 256KB
+0xEE800000 0xEE8FFFFF device tree (alternate bank) 1MB
+0xEE020000 0xEE6FFFFF Linux.uImage (alternate bank) 6MB+896KB
+0xEE000000 0xEE01FFFF RCW (alternate bank) 128KB
+0xEDF80000 0xEDFFFFFF u-boot (alternate bank) 512KB
+0xEDF60000 0xEDF7FFFF u-boot env (alternate bank) 128KB
+0xEDF40000 0xEDF5FFFF FMAN ucode (alternate bank) 128KB
+0xED300000 0xEDF3FFFF rootfs (current bank) 12MB+256MB
+0xEC800000 0xEC8FFFFF device tree (current bank) 1MB
+0xEC020000 0xEC6FFFFF Linux.uImage (current bank) 6MB+896KB
+0xEC000000 0xEC01FFFF RCW (current bank) 128KB
+
+Various Software configurations/environment variables/commands
+--------------------------------------------------------------
+The below commands apply to both B4860QDS and B4420QDS.
+
+1. U-boot environment variable hwconfig
+ The default hwconfig is:
+ hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=cs0_cs1;usb1:
+ dr_mode=host,phy_type=ulpi
+ Note: For USB gadget set "dr_mode=peripheral"
+
+2. FMAN Ucode versions
+ fsl_fman_ucode_B4860_106_3_6.bin
+
+3. Switching to alternate bank
+ Commands for switching to alternate bank.
+
+ 1. To change from vbank0 to vbank2
+ => qixis_reset altbank (it will boot using vbank2)
+
+ 2.To change from vbank2 to vbank0
+ => qixis reset (it will boot using vbank0)
+
+4. To change personality of board
+ For changing personality from B4860 to B4420
+ 1)Boot from vbank0
+ 2)Flash vbank2 with b4420 rcw and u-boot
+ 3)Give following commands to uboot prompt
+ => mw.b ffdf0040 0x30;
+ => mw.b ffdf0010 0x00;
+ => mw.b ffdf0062 0x02;
+ => mw.b ffdf0050 0x02;
+ => mw.b ffdf0010 0x30;
+ => reset
+
+ Note: Power off cycle will lead to default switch settings.
+ Note: 0xffdf0000 is the address of the QIXIS FPGA.
+
+5. Switching between NOR and NAND boot(RCW src changed from NOR <-> NAND)
+
+ To change from NOR to NAND boot give following command on uboot prompt
+ => mw.b ffdf0040 0x30
+ => mw.b ffdf0010 0x00
+ => mw.b 0xffdf0050 0x08
+ => mw.b 0xffdf0060 0x82
+ => mw.b ffdf0061 0x00
+ => mw.b ffdf0010 0x30
+ => reset
+
+ To change from NAND to NOR boot give following command on uboot prompt:
+ => mw.b ffdf0040 0x30
+ => mw.b ffdf0010 0x00
+ => mw.b 0xffdf0050 0x00(for vbank0) or (mw.b 0xffdf0050 0x02 for vbank2)
+ => mw.b 0xffdf0060 0x12
+ => mw.b ffdf0061 0x01
+ => mw.b ffdf0010 0x30
+ => reset
+
+ Note: Power off cycle will lead to default switch settings.
+ Note: 0xffdf0000 is the address of the QIXIS FPGA.
+
+6. Ethernet interfaces for B4860QDS
+ Serdes protocosl tested:
+ 0x2a, 0x8d (serdes1, serdes2) [DEFAULT]
+ 0x2a, 0xb2 (serdes1, serdes2)
+
+ When using [DEFAULT] RCW, which including 2 * 1G SGMII on board and 2 * 1G
+ SGMII on SGMII riser card.
+ Under U-boot these network interfaces are recognized as:
+ FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 and FM1@DTSEC6.
+
+ On Linux the interfaces are renamed as:
+ . eth2 -> fm1-gb2
+ . eth3 -> fm1-gb3
+ . eth4 -> fm1-gb4
+ . eth5 -> fm1-gb5
+
+7. RCW and Ethernet interfaces for B4420QDS
+ Serdes protocosl tested:
+ 0x18, 0x9e (serdes1, serdes2)
+
+ Under U-boot these network interfaces are recognized as:
+ FM1@DTSEC3, FM1@DTSEC4 and e1000#0.
+
+ On Linux the interfaces are renamed as:
+ . eth2 -> fm1-gb2
+ . eth3 -> fm1-gb3
diff --git a/marvell/uboot/doc/README.bedbug b/marvell/uboot/doc/README.bedbug
new file mode 100644
index 0000000..35e9d27
--- /dev/null
+++ b/marvell/uboot/doc/README.bedbug
@@ -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.
diff --git a/marvell/uboot/doc/README.bitbangMII b/marvell/uboot/doc/README.bitbangMII
new file mode 100644
index 0000000..0a2fa48
--- /dev/null
+++ b/marvell/uboot/doc/README.bitbangMII
@@ -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>
diff --git a/marvell/uboot/doc/README.blackfin b/marvell/uboot/doc/README.blackfin
new file mode 100644
index 0000000..a837d90
--- /dev/null
+++ b/marvell/uboot/doc/README.blackfin
@@ -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
diff --git a/marvell/uboot/doc/README.bootmenu b/marvell/uboot/doc/README.bootmenu
new file mode 100644
index 0000000..af22a13
--- /dev/null
+++ b/marvell/uboot/doc/README.bootmenu
@@ -0,0 +1,99 @@
+/*
+ * (C) Copyright 2011-2012 Pali Rohár <pali.rohar@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+ANSI terminal bootmenu command
+
+The "bootmenu" command uses U-Boot menu interfaces and provides
+a simple mechanism for creating menus with different boot items.
+The cursor keys "Up" and "Down" are used for navigation through
+the items. Current active menu item is highlighted and can be
+selected using the "Enter" key. The selection of the highlighted
+menu entry invokes an U-Boot command (or a list of commands)
+associated with this menu entry.
+
+The "bootmenu" command interprets ANSI escape sequencies, so
+an ANSI terminal is required for proper menu rendering and item
+selection.
+
+The assembling of the menu is done via a set of environment variables
+"bootmenu_<num>" and "bootmenu_delay", i.e.:
+
+ bootmenu_delay=<delay>
+ bootmenu_<num>="<title>=<commands>"
+
+ <delay> is the autoboot delay in seconds, after which the first
+ menu entry will be selected automatically
+
+ <num> is the boot menu entry number, starting from zero
+
+ <title> is the text of the menu entry shown on the console
+ or on the boot screen
+
+ <commands> are commands which will be executed when a menu
+ entry is selected
+
+ (title and commands are separated by first appearance of '='
+ character in the environment variable)
+
+First (optional) argument of the "bootmenu" command is a delay specifier
+and it overrides the delay value defined by "bootmenu_delay" environment
+variable. If the environment variable "bootmenu_delay" is not set or if
+the argument of the "bootmenu" command is not specified, the default delay
+will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on
+the console (or on the screen) and the command of the first menu entry will
+be called immediately. If delay is less then 0, bootmenu will be shown and
+autoboot will be disabled.
+
+Bootmenu always adds menu entry "U-Boot console" at the end of all menu
+entries specified by environment variables. When selecting this entry
+the bootmenu terminates and the usual U-Boot command prompt is presented
+to the user.
+
+Example environment:
+
+ setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry
+ setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry
+ setenv bootmenu_2 Reset board=reset # Set third menu entry
+ setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry
+ bootmenu 20 # Run bootmenu with autoboot delay 20s
+
+
+The above example will be rendered as below
+(without decorating rectangle):
+
+┌──────────────────────────────────────────┐
+│ │
+│ *** U-Boot Boot Menu *** │
+│ │
+│ Boot 1. kernel │
+│ Boot 2. kernel │
+│ Reset board │
+│ U-Boot boot order │
+│ U-Boot console │
+│ │
+│ Hit any key to stop autoboot: 20 │
+│ Press UP/DOWN to move, ENTER to select │
+│ │
+└──────────────────────────────────────────┘
+
+Selected menu entry will be highlighted - it will have inverted
+background and text colors.
+
+To enable the "bootmenu" command add following definitions to the
+board config file:
+
+ #define CONFIG_CMD_BOOTMENU
+ #define CONFIG_MENU
+
+To run the bootmenu at startup add these additional definitions:
+
+ #define CONFIG_AUTOBOOT_KEYED
+ #define CONFIG_BOOTDELAY 30
+ #define CONFIG_MENU_SHOW
+
+When you intend to use the bootmenu on color frame buffer console,
+make sure to additionally define CONFIG_CFB_CONSOLE_ANSI in the
+board config file.
diff --git a/marvell/uboot/doc/README.bus_vcxk b/marvell/uboot/doc/README.bus_vcxk
new file mode 100644
index 0000000..5bd3c65
--- /dev/null
+++ b/marvell/uboot/doc/README.bus_vcxk
@@ -0,0 +1,68 @@
+/*
+ * (C) Copyright 2008-2009
+ * BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de>
+ * Jens Scharsig <esw@bus-elektronik.de>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+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
diff --git a/marvell/uboot/doc/README.cfi b/marvell/uboot/doc/README.cfi
new file mode 100644
index 0000000..d087ff0
--- /dev/null
+++ b/marvell/uboot/doc/README.cfi
@@ -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
diff --git a/marvell/uboot/doc/README.commands b/marvell/uboot/doc/README.commands
new file mode 100644
index 0000000..9eb3671
--- /dev/null
+++ b/marvell/uboot/doc/README.commands
@@ -0,0 +1,36 @@
+
+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 and placed by
+the linker in a special section using the linker lists mechanism
+(see include/linker_lists.h)
+
+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 array can be iterated over using the linker lists macros.
+
+The linker lists feature ensures that the linker does not discard
+these symbols when linking full U-Boot even though they are not
+referenced in the source code as such.
+
+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_list : {
+ KEEP(*(SORT(.u_boot_list*)));
+ }
diff --git a/marvell/uboot/doc/README.commands.itest b/marvell/uboot/doc/README.commands.itest
new file mode 100644
index 0000000..5e0fe86
--- /dev/null
+++ b/marvell/uboot/doc/README.commands.itest
@@ -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; ....
diff --git a/marvell/uboot/doc/README.commands.spl b/marvell/uboot/doc/README.commands.spl
new file mode 100644
index 0000000..ac33273
--- /dev/null
+++ b/marvell/uboot/doc/README.commands.spl
@@ -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
diff --git a/marvell/uboot/doc/README.console b/marvell/uboot/doc/README.console
new file mode 100644
index 0000000..c9ef59e
--- /dev/null
+++ b/marvell/uboot/doc/README.console
@@ -0,0 +1,102 @@
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+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
diff --git a/marvell/uboot/doc/README.davinci b/marvell/uboot/doc/README.davinci
new file mode 100644
index 0000000..aa7c850
--- /dev/null
+++ b/marvell/uboot/doc/README.davinci
@@ -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
diff --git a/marvell/uboot/doc/README.davinci.nand_spl b/marvell/uboot/doc/README.davinci.nand_spl
new file mode 100644
index 0000000..f46721a
--- /dev/null
+++ b/marvell/uboot/doc/README.davinci.nand_spl
@@ -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 ...
diff --git a/marvell/uboot/doc/README.designware_eth b/marvell/uboot/doc/README.designware_eth
new file mode 100644
index 0000000..25ec6bd
--- /dev/null
+++ b/marvell/uboot/doc/README.designware_eth
@@ -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.
diff --git a/marvell/uboot/doc/README.displaying-bmps b/marvell/uboot/doc/README.displaying-bmps
new file mode 100644
index 0000000..3311541
--- /dev/null
+++ b/marvell/uboot/doc/README.displaying-bmps
@@ -0,0 +1,27 @@
+If you are experiencing hangups/data-aborts when trying to display a BMP image,
+the following might be relevant to your situation...
+
+Some architectures cannot handle unaligned memory accesses, and an attempt to
+perform one will lead to a data abort. On such architectures it is necessary to
+make sure all data is properly aligned, and in many situations simply choosing
+a 32 bit aligned address is enough to ensure proper alignment. This is not
+always the case when dealing with data that has an internal layout such as a
+BMP image:
+
+BMP images have a header that starts with 2 byte-size fields followed by mostly
+32 bit fields. The packed struct that represents this header can be seen below:
+
+typedef struct bmp_header {
+ /* Header */
+ char signature[2];
+ __u32 file_size;
+ __u32 reserved;
+ __u32 data_offset;
+ ... etc
+} __attribute__ ((packed)) bmp_header_t;
+
+When placed in an aligned address such as 0x80a00000, char signature offsets
+the __u32 fields into unaligned addresses (in our example 0x80a00002,
+0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit
+access is generated at a non-32-bit-aligned address, causing a data abort.
+The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2.
diff --git a/marvell/uboot/doc/README.dns b/marvell/uboot/doc/README.dns
new file mode 100644
index 0000000..8dff454
--- /dev/null
+++ b/marvell/uboot/doc/README.dns
@@ -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
diff --git a/marvell/uboot/doc/README.drivers.eth b/marvell/uboot/doc/README.drivers.eth
new file mode 100644
index 0000000..eb83038
--- /dev/null
+++ b/marvell/uboot/doc/README.drivers.eth
@@ -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.
diff --git a/marvell/uboot/doc/README.enetaddr b/marvell/uboot/doc/README.enetaddr
new file mode 100644
index 0000000..1eaeaf9
--- /dev/null
+++ b/marvell/uboot/doc/README.enetaddr
@@ -0,0 +1,116 @@
+---------------------------------
+ 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. The environment variable will be compared to the driver initialized
+ struct eth_device->enetaddr. If they differ, a warning is printed, and the
+ environment variable will be used unchanged.
+ If the environment variable is not set, it will be initialized from
+ eth_device->enetaddr, and a warning will be printed.
+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" */
diff --git a/marvell/uboot/doc/README.ext4 b/marvell/uboot/doc/README.ext4
new file mode 100644
index 0000000..9a2de50
--- /dev/null
+++ b/marvell/uboot/doc/README.ext4
@@ -0,0 +1,59 @@
+This patch series adds support for ext4 ls,load and write features in uboot
+Journaling is supported for write feature.
+
+To enable support for the ext4 (and ext2) filesystem implementation,
+#define CONFIG_FS_EXT4
+
+If you want write support,
+#define CONFIG_EXT4_WRITE
+
+To Enable ext2 ls and load commands, modify the board specific config file with
+#define CONFIG_CMD_EXT2
+This automatically defines CONFIG_FS_EXT4 for you.
+
+To Enable ext4 ls and load commands, modify the board specific config file with
+#define CONFIG_CMD_EXT4
+This automatically defines CONFIG_FS_EXT4 for you.
+
+To enable ext4 write command, modify the board specific config file with
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
+These automatically define CONFIG_FS_EXT4 and CONFIG_EXT4_WRITE for you.
+
+Also relevant are the generic filesystem commands,
+#define CONFIG_CMD_FS_GENERIC
+This does not automatically enable EXT4 support for you.
+
+Steps to test:
+
+1. After applying the patch, ext4 specific commands can be seen
+ in the boot loader prompt using
+ UBOOT #help
+
+ ext4load- load binary file from a Ext4 file system
+ ext4ls - list files in a directory (default /)
+ ext4write- create a file in ext4 formatted partition
+
+2. To list the files in ext4 formatted partition, execute
+ ext4ls <interface> <dev[:part]> [directory]
+ For example:
+ UBOOT #ext4ls mmc 0:5 /usr/lib
+
+3. To read and load a file from an ext4 formatted partition to RAM, execute
+ ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
+ For example:
+ UBOOT #ext4load mmc 2:2 0x30007fc0 uImage
+
+4. To write a file to a ext4 formatted partition.
+ a) First load a file to RAM at a particular address for example 0x30007fc0.
+ Now execute ext4write command
+ ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes]
+ For example:
+ UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120
+ (here 6183120 is the size of the file to be written)
+ Note: Absolute path is required for the file to be written
+
+References :
+ -- ext4 implementation in Linux Kernel
+ -- Uboot existing ext2 load and ls implementation
+ -- Journaling block device JBD2 implementation in linux Kernel
diff --git a/marvell/uboot/doc/README.falcon b/marvell/uboot/doc/README.falcon
new file mode 100644
index 0000000..6357b1e
--- /dev/null
+++ b/marvell/uboot/doc/README.falcon
@@ -0,0 +1,211 @@
+U-Boot Falcon Mode
+====================
+
+Introduction
+------------
+
+This document provides an overview of how to add support for Falcon Mode
+to a board.
+
+Falcon Mode is introduced to speed up the booting process, allowing
+to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
+U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
+image. In most implementations, SPL is used to start U-Boot when booting from
+a mass storage, such as NAND or SD-Card. SPL has now support for other media,
+and can generally be seen as a way to start an image performing the minimum
+required initialization. SPL mainly initializes the RAM controller, and then
+copies U-Boot image into the memory.
+
+The Falcon Mode extends this way allowing to start the Linux kernel directly
+from SPL. A new command is added to U-Boot to prepare the parameters that SPL
+must pass to the kernel, using ATAGS or Device Tree.
+
+In normal mode, these parameters are generated each time before
+loading the kernel, passing to Linux the address in memory where
+the parameters can be read.
+With Falcon Mode, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
+
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+
+1. Boot the board into U-Boot.
+Use the "spl export" command to generate the kernel parameters area or the DT.
+U-Boot runs as when it boots the kernel, but stops before passing the control
+to the kernel.
+
+2. Save the prepared snapshot into persistent media.
+The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy
+the parameters which are saved in the persistent area to the required address.
+If a valid uImage is not found at the defined location, U-Boot will be
+booted instead.
+
+It is required to implement a custom mechanism to select if SPL loads U-Boot
+or another image.
+
+The value of a GPIO is a simple way to operate the selection, as well as
+reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
+SPL that U-Boot is not the only available image that SPL is able to start.
+
+Configuration
+----------------------------
+CONFIG_CMD_SPL Enable the "spl export" command.
+ The command "spl export" is then available in U-Boot
+ mode
+CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
+ copied by SPL.
+ In most cases, it is <start_of_ram> + 0x100
+
+CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored
+
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved.
+
+CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied
+
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+
+Function that a board must implement
+------------------------------------
+
+void spl_board_prepare_for_linux(void) : optional
+ Called from SPL before starting the kernel
+
+spl_start_uboot() : required
+ Returns "0" if SPL should start the kernel, "1" if U-Boot
+ must be started.
+
+
+Using spl command
+-----------------
+
+spl - SPL configuration
+
+Usage:
+
+spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
+
+img : "atags" or "fdt"
+kernel_addr : kernel is loaded as part of the boot process, but it is not started.
+ This is the address where a kernel image is stored.
+initrd_addr : Address of initial ramdisk
+ can be set to "-" if fdt_addr without initrd_addr is used
+fdt_addr : in case of fdt, the address of the device tree.
+
+The spl export command does not write to a storage media. The user is
+responsible to transfer the gathered information (assembled ATAGS list
+or prepared FDT) from temporary storage in RAM into persistant storage
+after each run of 'spl export'. Unfortunately the position of temporary
+storage can not be predicted nor provided at commandline, it depends
+highly on your system setup and your provided data (ATAGS or FDT).
+However at the end of an succesful 'spl export' run it will print the
+RAM address of temporary storage.
+Now the user have to save the generated BLOB from that printed address
+to the pre-defined address in persistent storage
+(CONFIG_CMD_SPL_NAND_OFS in case of NAND).
+The following example shows how to prepare the data for Falcon Mode on
+twister board with ATAGS BLOB.
+
+The "spl export" command is prepared to work with ATAGS and FDT. However,
+using FDT is at the moment untested. The ppc port (see a3m071 example
+later) prepares the fdt blob with the fdt command instead.
+
+
+Usage on the twister board:
+--------------------------------
+
+Using mtd names with the following (default) configuration
+for mtdparts:
+
+device nand0 <omap2-nand.0>, # parts = 9
+ #: name size offset mask_flags
+ 0: MLO 0x00080000 0x00000000 0
+ 1: u-boot 0x00100000 0x00080000 0
+ 2: env1 0x00040000 0x00180000 0
+ 3: env2 0x00040000 0x001c0000 0
+ 4: kernel 0x00600000 0x00200000 0
+ 5: bootparms 0x00040000 0x00800000 0
+ 6: splashimg 0x00200000 0x00840000 0
+ 7: mini 0x02800000 0x00a40000 0
+ 8: rootfs 0x1cdc0000 0x03240000 0
+
+
+twister => nand read 82000000 kernel
+
+NAND read: device 0 offset 0x200000, size 0x600000
+ 6291456 bytes read: OK
+
+Now the kernel is in RAM at address 0x82000000
+
+twister => spl export atags 0x82000000
+## Booting kernel from Legacy Image at 82000000 ...
+ Image Name: Linux-3.5.0-rc4-14089-gda0b7f4
+ Image Type: ARM Linux Kernel Image (uncompressed)
+ Data Size: 3654808 Bytes = 3.5 MiB
+ Load Address: 80008000
+ Entry Point: 80008000
+ Verifying Checksum ... OK
+ Loading Kernel Image ... OK
+OK
+cmdline subcommand not supported
+bdt subcommand not supported
+Argument image is now in RAM at: 0x80000100
+
+The result can be checked at address 0x80000100:
+
+twister => md 0x80000100
+80000100: 00000005 54410001 00000000 00000000 ......AT........
+80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot
+80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs
+
+The parameters generated with this step can be saved into NAND at the offset
+0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS)
+
+nand erase.part bootparms
+nand write 0x80000100 bootparms 0x4000
+
+Now the parameters are stored into the NAND flash at the address
+CONFIG_CMD_SPL_NAND_OFS (=0x800000).
+
+Next time, the board can be started into Falcon Mode moving the
+setting the gpio (on twister gpio 55 is used) to kernel mode.
+
+The kernel is loaded directly by the SPL without passing through U-Boot.
+
+Example with FDT: a3m071 board
+-------------------------------
+
+To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
+prepard/patched first. U-Boot usually inserts some dynamic values into
+the DT binary (blob), e.g. autodetected memory size, MAC addresses,
+clocks speeds etc. To generate this patched DT blob, you can use
+the following command:
+
+1. Load fdt blob to SDRAM:
+=> tftp 1800000 a3m071/a3m071.dtb
+
+2. Set bootargs as desired for Linux booting (e.g. flash_mtd):
+=> run mtdargs addip2 addtty
+
+3. Use "fdt" commands to patch the DT blob:
+=> fdt addr 1800000
+=> fdt boardsetup
+=> fdt chosen
+
+4. Display patched DT blob (optional):
+=> fdt print
+
+5. Save fdt to NOR flash:
+=> erase fc060000 fc07ffff
+=> cp.b 1800000 fc060000 10000
+...
+
+
+Falcon Mode was presented at the RMLL 2012. Slides are available at:
+
+http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
diff --git a/marvell/uboot/doc/README.fdt-control b/marvell/uboot/doc/README.fdt-control
new file mode 100644
index 0000000..86bae68
--- /dev/null
+++ b/marvell/uboot/doc/README.fdt-control
@@ -0,0 +1,186 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+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.
+It is currently supported on ARM, x86 and Microblaze - other architectures
+will need to add code to their arch/xxx/lib/board.c file to locate the
+FDT. Alternatively you can enable generic board support on your board
+(with CONFIG_SYS_GENERIC_BOARD) if this is available (as it is for
+PowerPC). For ARM, Tegra and Exynos5 have device trees available for
+common devices.
+
+
+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 fdtdump utility for decoding a binary file, as
+well as fdtget/fdtput for reading and writing properties in 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.
+
+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.
+
+If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
+startup. This is only useful for sandbox. Use the -d flag to U-Boot to
+specify the file to read.
+
+You cannot use more than one 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"
+
+Build:
+
+After board configuration is done, fdt supported u-boot can be build in two ways:
+1) build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE
+ $ make
+2) build the user specified dts file
+ $ make DEVICE_TREE=<dts-file-name>
+
+
+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
diff --git a/marvell/uboot/doc/README.fec_mxc b/marvell/uboot/doc/README.fec_mxc
new file mode 100644
index 0000000..72a1d59
--- /dev/null
+++ b/marvell/uboot/doc/README.fec_mxc
@@ -0,0 +1,27 @@
+U-boot config options used in fec_mxc.c
+
+CONFIG_FEC_MXC
+ Selects fec_mxc.c to be compiled into u-boot.
+
+CONFIG_MII
+ Must be defined if CONFIG_FEC_MXC is defined.
+
+CONFIG_FEC_XCV_TYPE
+ Defaults to MII100 for 100 Base-tx.
+ RGMII selects 1000 Base-tx reduced pin count interface.
+ RMII selects 100 Base-tx reduced pin count interface.
+
+CONFIG_FEC_MXC_SWAP_PACKET
+ Forced on iff MX28.
+ Swaps the bytes order of all words(4 byte units) in the packet.
+ This should not be specified by a board file. It is cpu specific.
+
+CONFIG_PHYLIB
+ fec_mxc supports PHYLIB and should be used for new boards.
+
+CONFIG_FEC_MXC_NO_ANEG
+ Relevant only if PHYLIB not used. Skips auto-negotiation restart.
+
+CONFIG_FEC_MXC_PHYADDR
+ Optional, selects the exact phy address that should be connected
+ and function fecmxc_initialize will try to initialize it.
diff --git a/marvell/uboot/doc/README.fsl-ddr b/marvell/uboot/doc/README.fsl-ddr
new file mode 100644
index 0000000..1243a12
--- /dev/null
+++ b/marvell/uboot/doc/README.fsl-ddr
@@ -0,0 +1,430 @@
+Table of interleaving 2-4 controllers
+=====================================
+ +--------------+-----------------------------------------------------------+
+ |Configuration | Memory Controller |
+ | | 1 2 3 4 |
+ |--------------+--------------+--------------+-----------------------------+
+ | Two memory | Not Intlv'ed | Not Intlv'ed | |
+ | complexes +--------------+--------------+ |
+ | | 2-way Intlv'ed | |
+ |--------------+--------------+--------------+--------------+ |
+ | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | |
+ | Three memory +--------------+--------------+--------------+ |
+ | complexes | 2-way Intlv'ed | Not Intlv'ed | |
+ | +-----------------------------+--------------+ |
+ | | 3-way Intlv'ed | |
+ +--------------+--------------+--------------+--------------+--------------+
+ | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed |
+ | Four memory +--------------+--------------+--------------+--------------+
+ | complexes | 2-way Intlv'ed | 2-way Intlv'ed |
+ | +-----------------------------+-----------------------------+
+ | | 4-way Intlv'ed |
+ +--------------+-----------------------------------------------------------+
+
+
+Table of 2-way 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"
+
+ # 1KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_1KB"
+
+ # 4KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_4KB"
+
+ # 8KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_8KB"
+
+ # 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"
+
+ # bank(chip-select) interleaving (auto)
+ setenv hwconfig "fsl_ddr:bank_intlv=auto"
+ This auto mode only select from cs0_cs1_cs2_cs3, cs0_cs1, null dependings
+ on DIMMs.
+
+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 debugger can
+be activated by setting the environment variable "ddr_interactive" to any
+value. (The value of ddr_interactive may have a meaning in the future, but,
+for now, the presence of the variable will cause the debugger to run.) Once
+activated, U-boot will show the prompt "FSL DDR>" before enabling the DDR
+controller. The available commands are printed by typing "help".
+
+Another way to enter the interactive DDR debugger without setting the
+environment variable is to send the 'd' character early during the boot
+process. To save booting time, no additional delay is added, so the window
+to send the key press is very short -- basically, it is the time before the
+memory controller code starts to run. For example, when rebooting from
+within u-boot, the user must press 'd' IMMEDIATELY after hitting enter to
+initiate a 'reset' command. In case of power on/reset, the user can hold
+down the 'd' key while applying power or hitting the board's reset button.
+
+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 "copy" with arguments to copy controller/dimm settings
+type command "go" to continue calculation and enable DDR controller
+
+Additional commands to restart the debugging are:
+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", the debugger will program the
+DDR controller with the current setting without further calculation and then
+exit to resume the booting of the machine.
+
+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
+
+copy <src c#> <src d#> <spd|dimmparms|commonparms|opts|addresses|regs> <dst c#> <dst d#>
+ same as for "edit" command
+ DIMM numbers ignored for commonparms, opts, and regs
+
+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
+ FSL 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
+ =>
diff --git a/marvell/uboot/doc/README.fsl-hwconfig b/marvell/uboot/doc/README.fsl-hwconfig
new file mode 100644
index 0000000..e752505
--- /dev/null
+++ b/marvell/uboot/doc/README.fsl-hwconfig
@@ -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'
diff --git a/marvell/uboot/doc/README.fsl_iim b/marvell/uboot/doc/README.fsl_iim
new file mode 100644
index 0000000..e087f5e
--- /dev/null
+++ b/marvell/uboot/doc/README.fsl_iim
@@ -0,0 +1,48 @@
+Driver implementing the fuse API for Freescale's IC Identification Module (IIM)
+
+This IP can be found on the following SoCs:
+ - MPC512x,
+ - i.MX25,
+ - i.MX27,
+ - i.MX31,
+ - i.MX35,
+ - i.MX51,
+ - i.MX53.
+
+The section numbers in this file refer to the i.MX25 Reference Manual.
+
+A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1.
+
+A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1.
+
+Some fuse bit or word slots may not have the corresponding fuses actually
+implemented in the fusebox.
+
+See the README files of the SoCs using this driver in order to know the
+conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
+addresses.
+
+Fuse operations:
+
+ Read
+ Read operations are implemented as read accesses to the shadow registers,
+ using "Word y of Bank x" from the register summary in 30.3.2. This is
+ explained in detail in 30.4.5.1.
+
+ Sense
+ Sense operations are implemented as explained in 30.4.5.2.
+
+ Program
+ Program operations are implemented as explained in 30.4.5.3. Following
+ this operation, the shadow registers are reloaded by the hardware (not
+ immediately, but this does not make any difference for a user reading
+ these registers).
+
+ Override
+ Override operations are implemented as write accesses to the shadow
+ registers, as explained in 30.4.5.4.
+
+Configuration:
+
+ CONFIG_FSL_IIM
+ Define this to enable the fsl_iim driver.
diff --git a/marvell/uboot/doc/README.fuse b/marvell/uboot/doc/README.fuse
new file mode 100644
index 0000000..1bc91c4
--- /dev/null
+++ b/marvell/uboot/doc/README.fuse
@@ -0,0 +1,67 @@
+Fuse API functions and commands
+
+The fuse API allows to control a fusebox and how it is used by the upper
+hardware layers.
+
+A fuse corresponds to a single non-volatile memory bit that can be programmed
+(i.e. blown, set to 1) only once. The programming operation is irreversible. A
+fuse that has not been programmed reads 0.
+
+Fuses can be used by SoCs to store various permanent configuration and data,
+e.g. boot configuration, security configuration, MAC addresses, etc.
+
+A fuse word is the smallest group of fuses that can be read at once from the
+fusebox control IP registers. This is limited to 32 bits with the current API.
+
+A fuse bank is the smallest group of fuse words having a common ID, as defined
+by each SoC.
+
+Upon startup, the fusebox control IP reads the fuse values and stores them to a
+volatile shadow cache.
+
+See the README files of the drivers implementing this API in order to know the
+SoC- and implementation-specific details.
+
+Functions / commands:
+
+ int fuse_read(u32 bank, u32 word, u32 *val);
+ fuse read <bank> <word> [<cnt>]
+ Read fuse words from the shadow cache.
+
+ int fuse_sense(u32 bank, u32 word, u32 *val);
+ fuse sense <bank> <word> [<cnt>]
+ Sense - i.e. read directly from the fusebox, skipping the shadow cache -
+ fuse words. This operation does not update the shadow cache.
+
+ This is useful to know the true value of fuses if an override has been
+ performed (see below).
+
+ int fuse_prog(u32 bank, u32 word, u32 val);
+ fuse prog [-y] <bank> <word> <hexval> [<hexval>...]
+ Program fuse words. This operation directly affects the fusebox and is
+ irreversible. The shadow cache is updated accordingly or not, depending on
+ each IP.
+
+ Only the bits to be programmed should be set in the input value (i.e. for
+ fuse bits that have already been programmed and hence should be left
+ unchanged by a further programming, it is preferable to clear the
+ corresponding bits in the input value in order not to perform a new
+ hardware programming operation on these fuse bits).
+
+ int fuse_override(u32 bank, u32 word, u32 val);
+ fuse override <bank> <word> <hexval> [<hexval>...]
+ Override fuse words in the shadow cache.
+
+ The fusebox is unaffected, so following this operation, the shadow cache
+ may differ from the fusebox values. Read or sense operations can then be
+ used to get the values from the shadow cache or from the fusebox.
+
+ This is useful to change the behaviors linked to some cached fuse values,
+ either because this is needed only temporarily, or because some of the
+ fuses have already been programmed or are locked (if the SoC allows to
+ override a locked fuse).
+
+Configuration:
+
+ CONFIG_CMD_FUSE
+ Define this to enable the fuse commands.
diff --git a/marvell/uboot/doc/README.generic_usb_ohci b/marvell/uboot/doc/README.generic_usb_ohci
new file mode 100644
index 0000000..ba7cea8
--- /dev/null
+++ b/marvell/uboot/doc/README.generic_usb_ohci
@@ -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
diff --git a/marvell/uboot/doc/README.gpt b/marvell/uboot/doc/README.gpt
new file mode 100644
index 0000000..5c133f3
--- /dev/null
+++ b/marvell/uboot/doc/README.gpt
@@ -0,0 +1,178 @@
+#
+# Copyright (C) 2012 Samsung Electronics
+#
+# Lukasz Majewski <l.majewski@samsung.com>
+#
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+Glossary:
+========
+- UUID -(Universally Unique Identifier)
+- GUID - (Globally Unique ID)
+- EFI - (Extensible Firmware Interface)
+- UEFI - (Unified EFI) - EFI evolution
+- GPT (GUID Partition Table) - it is the EFI standard part
+- partitions - lists of available partitions (defined at u-boot):
+ ./include/configs/{target}.h
+
+Introduction:
+=============
+This document describes the GPT partition table format and usage of
+the gpt command in u-boot.
+
+UUID introduction:
+====================
+
+GPT for marking disks/partitions is using the UUID. It is supposed to be a
+globally unique value. A UUID is a 16-byte (128-bit) number. The number of
+theoretically possible UUIDs is therefore about 3 x 10^38.
+More often UUID is displayed as 32 hexadecimal digits, in 5 groups,
+separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters
+(32 digits and 4 hyphens)
+
+For instance, GUID of Linux data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
+
+Historically there are 5 methods to generate this number. The oldest one is
+combining machine's MAC address and timer (epoch) value.
+
+Successive versions are using MD5 hash, random numbers and SHA-1 hash. All major
+OSes and programming languages are providing libraries to compute UUID (e.g.
+uuid command line tool).
+
+GPT brief explanation:
+======================
+
+ Layout:
+ -------
+
+ --------------------------------------------------
+ LBA 0 |Protective MBR |
+ ----------------------------------------------------------
+ LBA 1 |Primary GPT Header | Primary
+ -------------------------------------------------- GPT
+ LBA 2 |Entry 1|Entry 2| Entry 3| Entry 4|
+ --------------------------------------------------
+ LBA 3 |Entries 5 - 128 |
+ | |
+ | |
+ ----------------------------------------------------------
+ LBA 34 |Partition 1 |
+ | |
+ -----------------------------------
+ |Partition 2 |
+ | |
+ -----------------------------------
+ |Partition n |
+ | |
+ ----------------------------------------------------------
+ LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4| Secondary
+ -------------------------------------------------- (bkp)
+ LBA -33 |Entries 5 - 128 | GPT
+ | |
+ | |
+ LBA -2 | |
+ --------------------------------------------------
+ LBA -1 |Secondary GPT Header |
+ ----------------------------------------------------------
+
+For a legacy reasons, GPT's LBA 0 sector has a MBR structure. It is called
+"protective MBR".
+Its first partition entry ID has 0xEE value, and disk software, which is not
+handling the GPT sees it as a storage device without free space.
+
+It is possible to define 128 linearly placed partition entries.
+
+"LBA -1" means the last addressable block (in the mmc subsystem:
+"dev_desc->lba - 1")
+
+Primary/Secondary GPT header:
+----------------------------
+Offset Size Description
+
+0 8 B Signature ("EFI PART", 45 46 49 20 50 41 52 54)
+8 4 B Revision (For version 1.0, the value is 00 00 01 00)
+12 4 B Header size (in bytes, usually 5C 00 00 00 meaning 92 bytes)
+16 4 B CRC32 of header (0 to header size), with this field zeroed
+ during calculation
+20 4 B Reserved (ZERO);
+24 8 B Current LBA (location of this header copy)
+32 8 B Backup LBA (location of the other header copy)
+40 8 B First usable LBA for partitions (primary partition table last
+ LBA + 1)
+48 8 B Last usable LBA (secondary partition table first LBA - 1)
+56 16 B Disk GUID (also referred as UUID on UNIXes)
+72 8 B Partition entries starting LBA (always 2 in primary copy)
+80 4 B Number of partition entries
+84 4 B Size of a partition entry (usually 128)
+88 4 B CRC32 of partition array
+92 * Reserved; must be ZERO (420 bytes for a 512-byte LBA)
+
+TOTAL: 512 B
+
+
+IMPORTANT:
+
+GPT headers and partition entries are protected by CRC32 (the POSIX CRC32).
+
+Primary GPT header and Secondary GPT header have swapped values of "Current LBA"
+and "Backup LBA" and therefore different CRC32 check-sum.
+
+CRC32 for GPT headers (field "CRC of header") are calculated up till
+"Header size" (92), NOT 512 bytes.
+
+CRC32 for partition entries (field "CRC32 of partition array") is calculated for
+the whole array entry ( Number_of_partition_entries *
+sizeof(partition_entry_size (usually 128)))
+
+Observe, how Secondary GPT is placed in the memory. It is NOT a mirror reflect
+of the Primary.
+
+ Partition Entry Format:
+ ----------------------
+ Offset Size Description
+
+ 0 16 B Partition type GUID
+ 16 16 B Unique partition GUID
+ 32 8 B First LBA (Little Endian)
+ 40 8 B Last LBA (inclusive)
+ 48 8 B Attribute flags [+]
+ 56 72 B Partition name (text)
+
+ Attribute flags:
+ Bit 0 - System partition
+ Bit 60 - Read-only
+ Bit 62 - Hidden
+ Bit 63 - Not mount
+
+Creating GPT partitions in U-Boot:
+==============
+
+To restore GUID partition table one needs to:
+1. Define partition layout in the environment.
+ Format of partitions layout:
+ "partitions=uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
+ name=kernel,size=60MiB,uuid=...;"
+ or
+ "partitions=uuid_disk=${uuid_gpt_disk};name=${uboot_name},
+ size=${uboot_size},uuid=${uboot_uuid};"
+
+ Fields 'name', 'size' and 'uuid' are mandatory for every partition.
+ The field 'start' is optional.
+
+2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT'
+
+2. From u-boot prompt type:
+ gpt write mmc 0 $partitions
+
+Useful info:
+============
+
+Two programs, namely: 'fdisk' and 'parted' are recommended to work with GPT
+recovery. Parted is able to handle GUID partitions. Unfortunately the 'fdisk'
+hasn't got such ability.
+Please, pay attention at -l switch for parted.
+
+"uuid" program is recommended to generate UUID string. Moreover it can decode
+(-d switch) passed in UUID string. It can be used to generate partitions UUID
+passed to u-boot environment variables.
diff --git a/marvell/uboot/doc/README.hwconfig b/marvell/uboot/doc/README.hwconfig
new file mode 100644
index 0000000..b6ddb43
--- /dev/null
+++ b/marvell/uboot/doc/README.hwconfig
@@ -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 environment 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.
diff --git a/marvell/uboot/doc/README.idma2intr b/marvell/uboot/doc/README.idma2intr
new file mode 100644
index 0000000..1828b51
--- /dev/null
+++ b/marvell/uboot/doc/README.idma2intr
@@ -0,0 +1,10 @@
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
+
+Attached is an IDMA example code for MPC8260/PPCBoot. I had tried to
+search around and could not find any for implementing IDMA, so
+implemented one. Its not coded in the best way, but works.
+
+Also, I was able to test the IDMA specific code under Linux also
+(with modifications). My requirement was to implement it for
+CompactFlash implemented in memory mode, and it works for it under
+PPCBoot and Linux.
diff --git a/marvell/uboot/doc/README.imx25 b/marvell/uboot/doc/README.imx25
new file mode 100644
index 0000000..0ca21b6
--- /dev/null
+++ b/marvell/uboot/doc/README.imx25
@@ -0,0 +1,10 @@
+U-Boot for Freescale i.MX25
+
+This file contains information for the port of U-Boot to the Freescale i.MX25
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in the words 26 to 31 of fuse bank 0, using the
+ natural MAC byte order (i.e. MSB first).
diff --git a/marvell/uboot/doc/README.imx27 b/marvell/uboot/doc/README.imx27
new file mode 100644
index 0000000..6f92cb4
--- /dev/null
+++ b/marvell/uboot/doc/README.imx27
@@ -0,0 +1,10 @@
+U-Boot for Freescale i.MX27
+
+This file contains information for the port of U-Boot to the Freescale i.MX27
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in the words 4 to 9 of fuse bank 0, using the
+ reversed MAC byte order (i.e. LSB first).
diff --git a/marvell/uboot/doc/README.imx31 b/marvell/uboot/doc/README.imx31
new file mode 100644
index 0000000..91ef766
--- /dev/null
+++ b/marvell/uboot/doc/README.imx31
@@ -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.
diff --git a/marvell/uboot/doc/README.imx5 b/marvell/uboot/doc/README.imx5
new file mode 100644
index 0000000..c5312b6
--- /dev/null
+++ b/marvell/uboot/doc/README.imx5
@@ -0,0 +1,28 @@
+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.
+
+1.2 CONFIG_SYS_MAIN_PWR_ON: Trigger MAIN_PWR_ON upon startup.
+ This option should be enabled for boards having a SYS_ON_OFF_CTL signal
+ connected to GPIO1[23] and triggering the MAIN_PWR_ON signal like in the
+ reference designs.
+
+2. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+2.1 MAC Address: It is stored in the words 9 to 14 of fuse bank 1, using the
+ natural MAC byte order (i.e. MSB first).
diff --git a/marvell/uboot/doc/README.imx6 b/marvell/uboot/doc/README.imx6
new file mode 100644
index 0000000..437af2f
--- /dev/null
+++ b/marvell/uboot/doc/README.imx6
@@ -0,0 +1,86 @@
+U-Boot for Freescale i.MX6
+
+This file contains information for the port of U-Boot to the Freescale i.MX6
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in fuse bank 4, with the 32 lsbs in word 2 and the
+ 16 msbs in word 3.
+
+Example:
+
+For reading the MAC address fuses on a MX6Q:
+
+- The MAC address is stored in two fuse addresses (the fuse addresses are
+described in the Fusemap Descriptions table from the mx6q Reference Manual):
+
+0x620[31:0] - MAC_ADDR[31:0]
+0x630[15:0] - MAC_ADDR[47:32]
+
+In order to use the fuse API, we need to pass the bank and word values, which
+are calculated as below:
+
+Fuse address for the lower MAC address: 0x620
+Base address for the fuses: 0x400
+
+(0x620 - 0x400)/0x10 = 0x22 = 34 decimal
+
+As the fuses are arranged in banks of 8 words:
+
+34 / 8 = 4 and the remainder is 2, so in this case:
+
+bank = 4
+word = 2
+
+And the U-boot command would be:
+
+=> fuse read 4 2
+Reading bank 4:
+
+Word 0x00000002: 9f027772
+
+Doing the same for the upper MAC address:
+
+Fuse address for the upper MAC address: 0x630
+Base address for the fuses: 0x400
+
+(0x630 - 0x400)/0x10 = 0x23 = 35 decimal
+
+As the fuses are arranged in banks of 8 words:
+
+35 / 8 = 4 and the remainder is 3, so in this case:
+
+bank = 4
+word = 3
+
+And the U-boot command would be:
+
+=> fuse read 4 3
+Reading bank 4:
+
+Word 0x00000003: 00000004
+
+,which matches the ethaddr value:
+=> echo ${ethaddr}
+00:04:9f:02:77:72
+
+Some other useful hints:
+
+- The 'bank' and 'word' numbers can be easily obtained from the mx6 Reference
+Manual. For the mx6quad case, please check the "46.5 OCOTP Memory Map/Register
+Definition" from the "i.MX 6Dual/6Quad Applications Processor Reference Manual,
+Rev. 1, 04/2013" document. For example, for the MAC fuses we have:
+
+Address:
+21B_C620 Value of OTP Bank4 Word2 (MAC Address)(OCOTP_MAC0)
+
+21B_C630 Value of OTP Bank4 Word3 (MAC Address)(OCOTP_MAC1)
+
+- The command '=> fuse read 4 2 2' reads the whole MAC addresses at once:
+
+=> fuse read 4 2 2
+Reading bank 4:
+
+Word 0x00000002: 9f027772 00000004
diff --git a/marvell/uboot/doc/README.imximage b/marvell/uboot/doc/README.imximage
new file mode 100644
index 0000000..dcda200
--- /dev/null
+++ b/marvell/uboot/doc/README.imximage
@@ -0,0 +1,239 @@
+---------------------------------------------
+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.
+
+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_OFFSET value
+
+ This command is parallel to BOOT_FROM and
+ is preferred over BOOT_FROM.
+
+ value: Offset of the image header, this
+ value shall be set to one of the
+ values found in the file:
+ arch/arm/include/asm/\
+ imx-common/imximage.cfg
+ Example:
+ BOOT_OFFSET FLASH_OFFSET_STANDARD
+
+ BOOT_FROM nand/spi/sd/onenand/nor/sata
+
+ This command is parallel to BOOT_OFFSET and
+ is to be deprecated in favor of BOOT_OFFSET.
+
+ Example:
+ BOOT_FROM spi
+
+ CSF value
+
+ Total size of CSF (Command Sequence File)
+ used for Secure Boot/ High Assurance Boot
+ (HAB).
+
+ Using this command will populate the IVT
+ (Initial Vector Table) CSF pointer and adjust
+ the length fields only. The CSF itself needs
+ to be generated with Freescale tools and
+ 'manually' appended to the u-boot.imx file.
+
+ The CSF is then simply concatenated
+ to the u-boot image, making a signed bootloader,
+ that the processor can verify
+ if the fuses for the keys are burned.
+
+ Further infos how to configure the SOC to verify
+ the bootloader can be found in the "High
+ Assurance Boot Version Application Programming
+ Interface Reference Manual" as part of the
+ Freescale Code Signing Tool, available on the
+ manufacturer's website.
+
+ Example:
+ CSF 0x2000
+
+ 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>
diff --git a/marvell/uboot/doc/README.iomux b/marvell/uboot/doc/README.iomux
new file mode 100644
index 0000000..044240d
--- /dev/null
+++ b/marvell/uboot/doc/README.iomux
@@ -0,0 +1,90 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+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).
diff --git a/marvell/uboot/doc/README.kwbimage b/marvell/uboot/doc/README.kwbimage
new file mode 100644
index 0000000..8ed708c
--- /dev/null
+++ b/marvell/uboot/doc/README.kwbimage
@@ -0,0 +1,104 @@
+---------------------------------------------
+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
+
+
+kwbimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash. The make target
+which uses mkimage to produce such an image is "u-boot.kwb". For example:
+
+ export BUILD_DIR=/tmp/build
+ make distclean
+ make yourboard_config
+ make $BUILD_DIR/u-boot.kwb
+
+
+Board specific configuration file specifications:
+------------------------------------------------
+1. This file must present in the $(BOARDDIR). The default name is
+ kwbimage.cfg. The name can be set as part of the full path
+ to the file using CONFIG_SYS_KWD_CONFIG (probably in
+ include/configs/<yourboard>.h). The path should look like:
+ $(SRCTREE)/$(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg
+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>
diff --git a/marvell/uboot/doc/README.link-local b/marvell/uboot/doc/README.link-local
new file mode 100644
index 0000000..9586eca
--- /dev/null
+++ b/marvell/uboot/doc/README.link-local
@@ -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" \
diff --git a/marvell/uboot/doc/README.lynxkdi b/marvell/uboot/doc/README.lynxkdi
new file mode 100644
index 0000000..076f018
--- /dev/null
+++ b/marvell/uboot/doc/README.lynxkdi
@@ -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
diff --git a/marvell/uboot/doc/README.m54418twr b/marvell/uboot/doc/README.m54418twr
new file mode 100644
index 0000000..f69ae01
--- /dev/null
+++ b/marvell/uboot/doc/README.m54418twr
@@ -0,0 +1,244 @@
+Freescale MCF54418TWR ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created Mar 22, 2012
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m54418twr/m54418twr.c Dram setup
+- board/freescale/m54418twr/Makefile Makefile
+- board/freescale/m54418twr/config.mk config make
+- board/freescale/m54418twr/u-boot.lds Linker description
+
+- 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.m54418twr 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
+
+- arch/m68k/include/asm/bitops.h Bit operation function export
+- arch/m68k/include/asm/byteorder.h Byte order functions
+- arch/m68k/include/asm/fec.h FEC structure and definition
+- arch/m68k/include/asm/global_data.h Global data structure
+- arch/m68k/include/asm/immap.h ColdFire specific header file and driver macros
+- arch/m68k/include/asm/immap_5441x.h mcf5441x specific header file
+- arch/m68k/include/asm/io.h io functions
+- arch/m68k/include/asm/m5441x.h mcf5441x specific header file
+- arch/m68k/include/asm/posix_types.h Posix
+- arch/m68k/include/asm/processor.h header file
+- arch/m68k/include/asm/ptrace.h Exception structure
+- arch/m68k/include/asm/rtc.h Realtime clock header file
+- arch/m68k/include/asm/string.h String function export
+- arch/m68k/include/asm/timer.h Timer structure and definition
+- arch/m68k/include/asm/types.h Data types definition
+- arch/m68k/include/asm/uart.h Uart structure and definition
+- arch/m68k/include/asm/u-boot.h u-boot structure
+
+- include/configs/M54418TWR.h Board specific configuration file
+
+- arch/m68k/lib/board.c board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts.c Coldfire common interrupt functions
+- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c Exception init code
+
+1 MCF5441x specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M54418TWR Development Board
+CONFIG_MCF5441x -- define for all MCF5441x CPUs
+CONFIG_M54418 -- define for all Freescale MCF54418 CPUs
+CONFIG_M54418TWR -- define for M54418TWR 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_MCFFEC -- define to use common CF FEC driver
+CONFIG_MII -- enable to use MII driver
+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_MCFTMR -- define to use DMA timer
+
+CONFIG_SYS_IMMR -- define for MBAR offset
+
+CONFIG_EXTRA_CLOCK -- Enable extra clock such as vco, flexbus, pci, etc
+
+CONFIG_SYS_MBAR -- define MBAR offset
+
+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_SDRAM_BASE -- defines the DRAM Base
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+ MRAM: 0x00000000-0x0003FFFF (256KB)
+ DDR: 0x40000000-0x47FFFFFF (128MB)
+ SRAM: 0x80000000-0x8000FFFF (64KB)
+ IP: 0xE0000000-0xFFFFFFFF (512MB)
+
+3. COMPILATION
+==============
+3.1 To create U-Boot the gcc-4.x compiler set (ColdFire ELF 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 M54418TWR_config, or - default to spi serial flash boot, 50Mhz input clock
+ make M54418TWR_nand_mii_config, or - default to nand flash boot, mii mode, 25Mhz input clock
+ make M54418TWR_nand_rmii_config, or - default to nand flash boot, rmii mode, 50Mhz input clock
+ make M54418TWR_nand_rmii_lowfreq_config, or - default to nand flash boot, rmii mode, 50Mhz input clock
+ make M54418TWR_serial_mii_config, or - default to spi serial flash boot, 25Mhz input clock
+ make M54418TWR_serial_rmii_config, or - default to spi serial flash boot, 50Mhz input clock
+ make
+
+4. SCREEN DUMP
+==============
+4.1 M54418TWR Development board
+ Boot from NAND flash (NOTE: May not show exactly the same)
+
+U-Boot 2012.10-00209-g12ae1d8-dirty (Oct 18 2012 - 15:54:54)
+
+CPU: Freescale MCF54418 (Mask:a3 Version:1)
+ CPU CLK 250 MHz BUS CLK 125 MHz FLB CLK 125 MHz
+ INP CLK 50 MHz VCO CLK 500 MHz
+Board: Freescale MCF54418 Tower System
+SPI: ready
+DRAM: 128 MiB
+NAND: 256 MiB
+In: serial
+Out: serial
+Err: serial
+Net: FEC0, FEC1
+-> pri
+baudrate=115200
+bootargs=root=/dev/mtdblock2 rw rootfstype=jffs2 mtdparts=NAND:1M(u-boot)ro,7M(k
+ernel)ro,-(jffs2) console=ttyS0,115200
+bootdelay=2
+eth1addr=00:e0:0c:bc:e5:61
+ethact=FEC0
+ethaddr=00:e0:0c:bc:e5:60
+fileaddr=40010000
+filesize=27354
+gatewayip=192.168.1.1
+hostname=M54418TWR
+inpclk=50000000
+ipaddr=192.168.1.2
+load=tftp ${loadaddr} ${u-boot};
+loadaddr=0x40010000
+mem=129024k
+netdev=eth0
+netmask=255.255.255.0
+prog=nand device 0;nand erase 0 40000;nb_update ${loadaddr} ${filesize};save
+serverip=192.168.1.1
+stderr=serial
+stdin=serial
+stdout=serial
+u-boot=u-boot.bin
+upd=run load; run prog
+
+Environment size: 653/131068 bytes
+-> bdinfo
+memstart = 0x40000000
+memsize = 0x08000000
+flashstart = 0x00000000
+flashsize = 0x00000000
+flashoffset = 0x00000000
+sramstart = 0x80000000
+sramsize = 0x00010000
+mbar = 0xFC000000
+cpufreq = 250 MHz
+busfreq = 125 MHz
+flbfreq = 125 MHz
+inpfreq = 50 MHz
+vcofreq = 500 MHz
+ethaddr = 00:e0:0c:bc:e5:60
+eth1addr = 00:e0:0c:bc:e5:61
+ip_addr = 192.168.1.2
+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
+dcache - enable or disable data cache
+dhcp - boot image via network using DHCP/TFTP protocol
+echo - echo args to console
+editenv - edit environment variable
+env - environment handling commands
+exit - exit script
+false - do nothing, unsuccessfully
+go - start application at address 'addr'
+help - print command description/usage
+icache - enable or disable instruction cache
+iminfo - print header information for application image
+imxtract- extract a part of a multi-image
+itest - return true/false on integer compare
+loop - infinite loop on address range
+md - memory display
+mdio - MDIO utility commands
+mii - MII utility commands
+mm - memory modify (auto-incrementing address)
+mtest - simple RAM read/write test
+mw - memory write (fill)
+nand - NAND sub-system
+nb_update- Nand boot update program
+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
+reginfo - print register information
+reset - Perform RESET of the CPU
+run - run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv - set environment variables
+sf - SPI flash sub-system
+showvar - print local hushshell variables
+sleep - delay execution for some time
+source - run script from memory
+sspi - SPI utility command
+test - minimal test like /bin/sh
+tftpboot- boot image via network using TFTP protocol
+true - do nothing, successfully
+version - print monitor, compiler and linker version
diff --git a/marvell/uboot/doc/README.m68k b/marvell/uboot/doc/README.m68k
new file mode 100644
index 0000000..c85febc
--- /dev/null
+++ b/marvell/uboot/doc/README.m68k
@@ -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/
diff --git a/marvell/uboot/doc/README.malta b/marvell/uboot/doc/README.malta
new file mode 100644
index 0000000..a495d02
--- /dev/null
+++ b/marvell/uboot/doc/README.malta
@@ -0,0 +1,16 @@
+MIPS Malta board
+
+How to flash using a MIPS Navigator Probe:
+
+ - Ensure that your Malta has jumper JP1 fitted. Without this jumper you will
+ be unable to flash your Malta using a Navigator Probe.
+
+ - Connect Navigator Console to your probe and Malta as usual.
+
+ - Within Navigator Console run the following commands:
+
+ source /path/to/u-boot/board/malta/flash-malta-boot.tcl
+ reset
+ flash-boot /path/to/u-boot/u-boot.bin
+
+ - You should now be able to reboot your Malta to a U-boot shell.
diff --git a/marvell/uboot/doc/README.marubun-pcmcia b/marvell/uboot/doc/README.marubun-pcmcia
new file mode 100644
index 0000000..d3563a3
--- /dev/null
+++ b/marvell/uboot/doc/README.marubun-pcmcia
@@ -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>
diff --git a/marvell/uboot/doc/README.memory-test b/marvell/uboot/doc/README.memory-test
new file mode 100644
index 0000000..eb60e8d
--- /dev/null
+++ b/marvell/uboot/doc/README.memory-test
@@ -0,0 +1,98 @@
+The most frequent cause of problems when porting U-Boot to new
+hardware, or when using a sloppy port on some board, is memory errors.
+In most cases these are not caused by failing hardware, but by
+incorrect initialization of the memory controller. So it appears to
+be a good idea to always test if the memory is working correctly,
+before looking for any other potential causes of any problems.
+
+U-Boot implements 3 different approaches to perform memory tests:
+
+1. The get_ram_size() function (see "common/memsize.c").
+
+ This function is supposed to be used in each and every U-Boot port
+ determine the presence and actual size of each of the potential
+ memory banks on this piece of hardware. The code is supposed to be
+ very fast, so running it for each reboot does not hurt. It is a
+ little known and generally underrated fact that this code will also
+ catch 99% of hardware related (i. e. reliably reproducible) memory
+ errors. It is strongly recommended to always use this function, in
+ each and every port of U-Boot.
+
+2. The "mtest" command.
+
+ This is probably the best known memory test utility in U-Boot.
+ Unfortunately, it is also the most problematic, and the most
+ useless one.
+
+ There are a number of serious problems with this command:
+
+ - It is terribly slow. Running "mtest" on the whole system RAM
+ takes a _long_ time before there is any significance in the fact
+ that no errors have been found so far.
+
+ - It is difficult to configure, and to use. And any errors here
+ will reliably crash or hang your system. "mtest" is dumb and has
+ no knowledge about memory ranges that may be in use for other
+ purposes, like exception code, U-Boot code and data, stack,
+ malloc arena, video buffer, log buffer, etc. If you let it, it
+ will happily "test" all such areas, which of course will cause
+ some problems.
+
+ - It is not easy to configure and use, and a large number of
+ systems are seriously misconfigured. The original idea was to
+ test basically the whole system RAM, with only exempting the
+ areas used by U-Boot itself - on most systems these are the areas
+ used for the exception vectors (usually at the very lower end of
+ system memory) and for U-Boot (code, data, etc. - see above;
+ these are usually at the very upper end of system memory). But
+ experience has shown that a very large number of ports use
+ pretty much bogus settings of CONFIG_SYS_MEMTEST_START and
+ CONFIG_SYS_MEMTEST_END; this results in useless tests (because
+ the ranges is too small and/or badly located) or in critical
+ failures (system crashes).
+
+ Because of these issues, the "mtest" command is considered depre-
+ cated. It should not be enabled in most normal ports of U-Boot,
+ especially not in production. If you really need a memory test,
+ then see 1. and 3. above resp. below.
+
+3. The most thorough memory test facility is available as part of the
+ POST (Power-On Self Test) sub-system, see "post/drivers/memory.c".
+
+ If you really need to perform memory tests (for example, because
+ it is mandatory part of your requirement specification), then
+ enable this test which is generic and should work on all archi-
+ tectures.
+
+WARNING:
+
+It should pointed out that _all_ these memory tests have one
+fundamental, unfixable design flaw: they are based on the assumption
+that memory errors can be found by writing to and reading from memory.
+Unfortunately, this is only true for the relatively harmless, usually
+static errors like shorts between data or address lines, unconnected
+pins, etc. All the really nasty errors which will first turn your
+hair gray, only to make you tear it out later, are dynamical errors,
+which usually happen not with simple read or write cycles on the bus,
+but when performing back-to-back data transfers in burst mode. Such
+accesses usually happen only for certain DMA operations, or for heavy
+cache use (instruction fetching, cache flushing). So far I am not
+aware of any freely available code that implements a generic, and
+efficient, memory test like that. The best known test case to stress
+a system like that is to boot Linux with root file system mounted over
+NFS, and then build some larger software package natively (say,
+compile a Linux kernel on the system) - this will cause enough context
+switches, network traffic (and thus DMA transfers from the network
+controller), varying RAM use, etc. to trigger any weak spots in this
+area.
+
+Note: An attempt was made once to implement such a test to catch
+memory problems on a specific board. The code is pretty much board
+specific (for example, it includes setting specific GPIO signals to
+provide triggers for an attached logic analyzer), but you can get an
+idea how it works: see "examples/standalone/test_burst*".
+
+Note 2: Ironically enough, the "test_burst" did not catch any RAM
+errors, not a single one ever. The problems this code was supposed
+to catch did not happen when accessing the RAM, but when reading from
+NOR flash.
diff --git a/marvell/uboot/doc/README.menu b/marvell/uboot/doc/README.menu
new file mode 100644
index 0000000..ad520ab
--- /dev/null
+++ b/marvell/uboot/doc/README.menu
@@ -0,0 +1,125 @@
+/*
+ * Copyright 2010-2011 Calxeda, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+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 *),
+ char *(*item_choice)(void *),
+ void *item_choice_data);
+
+/*
+ * 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_default_choice() - Set *choice to point to the default item's data
+ */
+int menu_default_choice(struct menu *m, void **choice);
+
+/*
+ * 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);
+ }
+}
diff --git a/marvell/uboot/doc/README.mips b/marvell/uboot/doc/README.mips
new file mode 100644
index 0000000..b28f628
--- /dev/null
+++ b/marvell/uboot/doc/README.mips
@@ -0,0 +1,54 @@
+
+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
+------------
+
+ * 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
+
+ * 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().
+
+ * centralize/share more CPU code of MIPS32, MIPS64 and XBurst
+
+ * support Qemu Malta
diff --git a/marvell/uboot/doc/README.mpc5xx b/marvell/uboot/doc/README.mpc5xx
new file mode 100644
index 0000000..df51b5c
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc5xx
@@ -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
diff --git a/marvell/uboot/doc/README.mpc74xx b/marvell/uboot/doc/README.mpc74xx
new file mode 100644
index 0000000..f81f1c2
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc74xx
@@ -0,0 +1,22 @@
+This file contains status information for the port of U-Boot to the
+Motorola mpc74xx series of CPUs.
+
+Author: Josh Huber <huber@mclx.com>
+ Mission Critical Linux, Inc.
+
+Currently the support for these CPUs is pretty minimal, but enough to
+get things going. (much like the support for the Galileo Eval Board)
+
+There is a framework in place to enable the L2 cache, and to program
+the BATs. Currently, there are still problems with the code which
+sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be
+anyway). Additionally, there is support for enabling the MMU, which
+we also don't do. The BATs are programmed just for the benefit of
+jumping into Linux in a sane configuration.
+
+Most of the code was based on other cpus supported by U-Boot.
+
+If you find any errors in the CPU setup code, please send us a note.
+
+Thanks,
+Josh
diff --git a/marvell/uboot/doc/README.mpc83xx.ddrecc b/marvell/uboot/doc/README.mpc83xx.ddrecc
new file mode 100644
index 0000000..0029f08
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc83xx.ddrecc
@@ -0,0 +1,154 @@
+Overview
+========
+
+The overall usage pattern for ECC diagnostic commands is the following:
+
+ * (injecting errors is initially disabled)
+
+ * define inject mask (which tells the DDR controller what type of errors
+ we'll be injecting: single/multiple bit etc.)
+
+ * enable injecting errors - from now on the controller injects errors as
+ indicated in the inject mask
+
+IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially
+dangerous as such errors are NOT corrected by the controller. Therefore caution
+should be taken when enabling the injection of multiple-bit errors: it is only
+safe when used on a carefully selected memory area and used under control of
+the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit
+Errors' below). In particular, when you simply set the multiple-bit errors in
+inject mask and enable injection, U-Boot is very likely to hang quickly as the
+errors will be injected when it accesses its code, data etc.
+
+
+Use cases for DDR 'ecc' command:
+================================
+
+Before executing particular tests reset target board or clear status registers:
+
+=> ecc captureclear
+=> ecc errdetectclr all
+=> ecc sbecnt 0
+
+
+Injecting Single-Bit Errors
+---------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Run test over some memory region
+
+=> ecc testdw 200000 10
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000000
+...
+Memory Single-Bit Error Management (0..255):
+ Single-Bit Error Threshold: 255
+ Single Bit Error Counter: 16
+...
+Memory Error Detect:
+ Multiple Memory Errors: 0
+ Multiple-Bit Error: 0
+ Single-Bit Error: 0
+...
+
+16 errors were generated, Single-Bit Error flag was not set as Single Bit Error
+Counter did not reach Single-Bit Error Threshold.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef ................
+00200090: deadbeef deadbeef deadbeef deadbeef ................
+
+Injecting Multiple-Bit Errors
+-----------------------------
+
+1. Set more than 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+=> ecc injectdatalo 1
+
+2. Run test over some memory region
+
+=> ecc testword 200000 1
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000001
+...
+Memory Error Detect:
+ Multiple Memory Errors: 0
+ Multiple-Bit Error: 1
+ Single-Bit Error: 0
+...
+
+The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef ................
+00200090: deadbeef deadbeef deadbeef deadbeef ................
+
+
+Test Single-Bit Error Counter and Threshold
+-------------------------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Enable error injection
+
+=> ecc inject en
+
+3. Let u-boot run for a with Single-Bit error injection enabled
+
+4. Disable error injection
+
+=> ecc inject dis
+
+4. Check status
+
+=> ecc status
+
+...
+Memory Single-Bit Error Management (0..255):
+ Single-Bit Error Threshold: 255
+ Single Bit Error Counter: 199
+
+Memory Error Detect:
+ Multiple Memory Errors: 1
+ Multiple-Bit Error: 0
+ Single-Bit Error: 1
+...
+
+Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter
+reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that
+is Counter reached Threshold more than one time (it wraps back after reaching
+Threshold).
diff --git a/marvell/uboot/doc/README.mpc83xxads b/marvell/uboot/doc/README.mpc83xxads
new file mode 100644
index 0000000..d456103
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc83xxads
@@ -0,0 +1,98 @@
+Freescale MPC83xx ADS Boards
+-----------------------------------------
+
+0. Toolchain / Building
+
+ $ PATH=$PATH:/usr/powerpc/bin
+ $ CROSS_COMPILE=powerpc-linux-
+ $ export PATH CROSS_COMPILE
+
+ $ powerpc-linux-gcc -v
+ Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs
+ Configured with: ../configure --prefix=/usr/powerpc
+ --exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared
+ --disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc
+ Thread model: posix
+ gcc version 3.4.3 (Debian)
+
+ $ powerpc-linux-as -v
+ GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15
+
+
+ $ make MPC8349ADS_config
+ Configuring for MPC8349ADS board...
+
+ $ make
+
+
+1. Board Switches and Jumpers
+
+
+2. Memory Map
+
+2.1. The memory map should look pretty much like this:
+
+ 0x0000_0000 0x7fff_ffff DDR 2G
+ 0x8000_0000 0x9fff_ffff PCI MEM 512M
+ 0xc000_0000 0xdfff_ffff Rapid IO 512M
+ 0xe000_0000 0xe00f_ffff CCSR 1M
+ 0xe200_0000 0xe2ff_ffff PCI IO 16M
+ 0xf000_0000 0xf7ff_ffff SDRAM 128M
+ 0xf800_0000 0xf80f_ffff BCSR 1M
+ 0xfe00_0000 0xffff_ffff FLASH (boot bank) 16M
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+ include/configs/MPC8349ADS.h
+
+ CONFIG_MPC83xx MPC83xx family
+ CONFIG_MPC8349 MPC8349 specific
+ CONFIG_MPC8349ADS MPC8349ADS board specific
+ CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet
+
+
+4. Compilation
+
+ Assuming you're using BASH shell:
+
+ export CROSS_COMPILE=your-cross-compile-prefix
+ cd u-boot
+ make distclean
+ make MPC8349ADS_config
+ make
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+ loadb
+ [Drop to kermit:
+ ^\c
+ send <u-boot-bin-image>
+ c
+ ]
+
+
+ Or via tftp:
+
+ tftp 10000 u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+ tftp 10000 u-boot.bin
+ protect off fe000000 fe09ffff
+ erase fe000000 fe09ffff
+
+ cp.b 10000 fe000000 xxxx
+or
+ cp.b 10000 fe000000 a0000
+
+You might have to supply the correct byte count for 'xxxx' from
+the TFTP. Maybe a0000 will work too, that corresponds to the
+erased sectors.
+
+
+6. Notes
diff --git a/marvell/uboot/doc/README.mpc85xx b/marvell/uboot/doc/README.mpc85xx
new file mode 100644
index 0000000..f9b023f
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc85xx
@@ -0,0 +1,166 @@
+External Debug Support
+----------------------
+
+Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some
+restrictions on external debugging (JTAG). In particular, for the debugger to
+be able to receive control after a single step or breakpoint:
+ - MSR[DE] must be set
+ - A valid opcode must be fetchable, through the MMU, from the debug
+ exception vector (IVPR + IVOR15).
+
+To maximize the time during which this requirement is met, U-Boot sets MSR[DE]
+immediately on entry and keeps it set. It also uses a temporary TLB to keep a
+mapping to a valid opcode at the debug exception vector, even if we normally
+don't support exception vectors being used that early, and that's not the area
+where U-Boot currently executes from.
+
+Note that there may still be some small windows where debugging will not work,
+such as in between updating IVPR and IVOR15.
+
+Config Switches:
+----------------
+
+Please refer README section "MPC85xx External Debug Support"
+
+Major Config Switches during various boot Modes
+----------------------------------------------
+
+NOR boot
+ !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SPL)
+NOR boot Secure
+ !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT)
+RAMBOOT(SD, SPI & NAND boot)
+ defined(CONFIG_SYS_RAMBOOT)
+RAMBOOT Secure (SD, SPI & NAND)
+ defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT)
+NAND SPL BOOT
+ defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NAND_SPL)
+
+
+TLB Entries during u-boot execution
+-----------------------------------
+
+Note: Sequence number is in order of execution
+
+A) defined(CONFIG_SYS_RAMBOOT) i.e. SD, SPI, NAND RAMBOOT & NAND_SPL boot
+
+ 1) TLB entry to overcome e500 v1/v2 debug restriction
+ Location : Label "_start_e500"
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
+ Properties : 256K, AS0, I, IPROT
+
+ 2) TLB entry for working in AS1
+ Location : Label "create_init_ram_area"
+ TLB Entry : 15
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
+ Properties : 1M, AS1, I, G, IPROT
+
+ 3) TLB entry for the stack during AS1
+ Location : Lable "create_init_ram_area"
+ TLB Entry : 14
+ EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR
+ Properties : 16K, AS1, IPROT
+
+ 4) TLB entry for CCSRBAR during AS1 execution
+ Location : cpu_init_early_f
+ TLB Entry : 13
+ EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR
+ Properties : 1M, AS1, I, G
+
+ 5) Invalidate unproctected TLB Entries
+ Location : cpu_init_early_f
+ Invalidated: 13
+
+ 6) Create TLB entries as per boards/freescale/<board>/tlb.c
+ Location : cpu_init_early_f --> init_tlbs()
+ Properties : ..., AS0, ...
+ Please note It can overwrites previous TLB Entries.
+
+ 7) Disable TLB Entries of AS1
+ Location : cpu_init_f --> disable_tlb()
+ Disable : 15, 14
+
+ 8) Update Flash's TLB entry
+ Location : Board_init_r
+ TLB entry : Search from TLB entries
+ EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS
+ Properties : Board specific size, AS0, I, G, IPROT
+
+
+B) !defined(CONFIG_SYS_RAMBOOT) i.e. NOR boot
+
+ 1) TLB entry to overcome e500 v1/v2 debug restriction
+ Location : Label "_start_e500"
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+#if defined(CONFIG_SECURE_BOOT)
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW
+ Properties : 1M, AS1, I, G, IPROT
+#else
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
+ Properties : 4M, AS0, I, G, IPROT
+#endif
+
+ 2) TLB entry for working in AS1
+ Location : Label "create_init_ram_area"
+ TLB Entry : 15
+#if defined(CONFIG_SECURE_BOOT)
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW
+ Properties : 1M, AS1, I, G, IPROT
+#else
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
+ Properties : 4M, AS1, I, G, IPROT
+#endif
+
+ 3) TLB entry for the stack during AS1
+ Location : Lable "create_init_ram_area"
+ TLB Entry : 14
+ EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR
+ Properties : 16K, AS1, IPROT
+
+ 4) TLB entry for CCSRBAR during AS1 execution
+ Location : cpu_init_early_f
+ TLB Entry : 13
+ EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR
+ Properties : 1M, AS1, I, G
+
+ 5) TLB entry for Errata workaround CONFIG_SYS_FSL_ERRATUM_IFC_A003399
+ Location : cpu_init_early_f
+ TLB Entry : 9
+ EPN -->RPN : SRAM_BASE_ADDR --> SRAM_BASE_ADDR
+ Properties : 1M, AS1, I
+
+ 6) CONFIG_SYS_FSL_ERRATUM_IFC_A003399 Adjust flash's phys addr
+ Location : cpu_init_early_f --> setup_ifc
+ TLB Entry : Get Flash TLB
+ EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
+ Properties : 4M, AS1, I, G, IPROT
+
+ 7) CONFIG_SYS_FSL_ERRATUM_IFC_A003399: E500 v1,v2 debug restriction
+ Location : cpu_init_early_f --> setup_ifc
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+ EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
+ Properties : 4M, AS0, I, G, IPROT
+
+ 8) Invalidate unproctected TLB Entries
+ Location : cpu_init_early_f
+ Invalidated: 13, 9
+
+ 9) Create TLB entries as per boards/freescale/<board>/tlb.c
+ Location : cpu_init_early_f --> init_tlbs()
+ Properties : ..., AS0, ...
+ Note: It can overwrites previous TLB Entries
+
+ 10) Disable TLB Entries of AS1
+ Location : cpu_init_f --> disable_tlb()
+ Disable : 15, 14
+
+ 11) Create DDR's TLB entriy
+ Location : Board_init_f -> init_func_ram -> initdram
+ TLB entry : Search free TLB entry
+
+ 12) Update Flash's TLB entry
+ Location : Board_init_r
+ TLB entry : Search from TLB entries
+ EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS
+ Properties : Board specific size, AS0, I, G, IPROT
diff --git a/marvell/uboot/doc/README.mpc85xx-sd-spi-boot b/marvell/uboot/doc/README.mpc85xx-sd-spi-boot
new file mode 100644
index 0000000..d5043cc
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc85xx-sd-spi-boot
@@ -0,0 +1,81 @@
+----------------------------------------
+Booting from On-Chip ROM (eSDHC or eSPI)
+----------------------------------------
+
+boot_format is a tool to write SD bootable images to a filesystem and build
+SD/SPI images to a binary file for writing later.
+
+When booting from an SD card/MMC, boot_format puts the configuration file and
+the RAM-based U-Boot image on the card.
+When booting from an EEPROM, boot_format generates a binary image that is used
+to boot from this EEPROM.
+
+Where to get boot_format:
+========================
+
+you can browse it online at:
+http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/
+
+Building
+========
+
+Run the following to build this project
+
+ $ make
+
+Execution
+=========
+
+boot_format runs under a regular Linux machine and requires a super user mode
+to run. Execute boot_format as follows.
+
+For building SD images by writing directly to a file system on SD media:
+
+ $ boot_format $config u-boot.bin -sd $device
+
+Where $config is the included config.dat file for your platform and $device
+is the target block device for the SD media on your computer.
+
+For build binary images directly a local file:
+
+ $ boot_format $config u-boot.bin -spi $file
+
+Where $file is the target file. Also keep in mind the u-boot.bin file needs
+to be the u-boot built for your particular platform and target media.
+
+Example: To generate a u-boot.bin for a P1022DS booting from SD, run the
+following in the u-boot repository:
+
+ $ make P1022DS_SDCARD
+
+Configuration Files
+===================
+
+Below are the configuration files to be used with a particular platform. Keep
+in mind that some of these config files are tied to the platforms DDR speed.
+Please see the SoC reference manual for more documentation.
+
+P1022DS config_sram_p1022ds.dat
+P2020DS config_sram_p2020ds.dat
+P2010DS config_sram_p2020ds.dat
+P1020RDB config_ddr2_1g_p1020rdb_533M.dat
+P1020RDB config_ddr2_1g_p1020rdb_667M.dat
+P2020RDB config_ddr2_1g_p2020rdb_800M.dat
+P2020RDB config_ddr2_1g_p2020rdb_667M.dat
+P2020RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat
+P2010RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat
+P1020RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1011RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1010RDB config_ddr3_1gb_p1010rdb_800M.dat
+P1014RDB config_ddr3_1gb_p1014rdb_800M.dat
+P1021RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1012RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1022DS config_ddr3_2gb_p1022ds.dat
+P1013DS config_ddr3_2gb_p1022ds.dat
+P1024RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1013RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1025RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1016RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1020UTM config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1020MBG config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+MPC8536DS config_ddr2_512m_mpc8536ds_667M.dat
diff --git a/marvell/uboot/doc/README.mpc85xx-spin-table b/marvell/uboot/doc/README.mpc85xx-spin-table
new file mode 100644
index 0000000..8da768a
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc85xx-spin-table
@@ -0,0 +1,26 @@
+Spin table in cache
+=====================================
+As specified by ePAPR v1.1, the spin table needs to be in cached memory. After
+DDR is initialized and U-boot relocates itself into DDR, the spin table is
+accessible for core 0. It is part of release.S, within 4KB range after
+__secondary_start_page. For other cores to use the spin table, the booting
+process is described below:
+
+Core 0 sets up the reset page on the top 4K of memory (or 4GB if total memory
+is more than 4GB), and creates a TLB to map it to 0xffff_f000, regardless of
+the physical address of this page, with WIMGE=0b01010. Core 0 also enables boot
+page translation for secondary cores to use this page of memory. Then 4KB
+memory is copied from __secondary_start_page to the boot page, after flusing
+cache because this page is mapped as normal DDR. Before copying the reset page,
+core 0 puts the physical address of the spin table (which is in release.S and
+relocated to the top of mapped memory) into a variable __spin_table_addr so
+that secondary cores can see it.
+
+When secondary cores boot up from 0xffff_f000 page, they only have one default
+TLB. While booting, they set up another TLB in AS=1 space and jump into
+the new space. The new TLB covers the physical address of the spin table page,
+with WIMGE =0b00100. Now secondary cores can keep polling the spin table
+without stress DDR bus because both the code and the spin table is in cache.
+
+For the above to work, DDR has to set the 'M' bit of WIMGE, in order to keep
+cache coherence.
diff --git a/marvell/uboot/doc/README.mpc85xxads b/marvell/uboot/doc/README.mpc85xxads
new file mode 100644
index 0000000..28bbcbe
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc85xxads
@@ -0,0 +1,303 @@
+Motorola MPC8540ADS and MPC8560ADS board
+
+Created 10/15/03 Xianghua Xiao
+Updated 13-July-2004 Jon Loeliger
+-----------------------------------------
+
+0. Toolchain
+
+ The Binutils in current ELDK toolchain will not support MPC85xx
+ chip. You need to use binutils-2.14.tar.bz2 (or newer) from
+ http://ftp.gnu.org/gnu/binutils.
+
+ The 8540/8560 ADS code base is known to compile using:
+ gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
+
+
+1. SWITCH SETTINGS & JUMPERS
+
+1.0 Nomenclature
+
+ For some reason, the HW designers describe the switch settings
+ in terms of 0 and 1, and then map that to physical switches where
+ the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1.
+ Luckily, we're SW types and virtual settings are handled daily.
+
+ The switches for the Rev A board are numbered differently than
+ for the Pilot board. Oh yeah.
+
+ Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
+ bits may contribute to signals that are numbered based at 0,
+ and some of those signals may be high-bit-number-0 too. Heed
+ well the names and labels and do not get confused.
+
+ "Off" == 1
+ "On" == 0
+
+ SW18 is switch 18 as silk-screened onto the board.
+ SW4[8] is the bit labeled 8 on Switch 4.
+ SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2
+ SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3
+
+1.1 For the MPC85xxADS Pilot Board
+
+ First, make sure the board default setting is consistent with the document
+ shipped with your board. Then apply the following changes:
+ SW3[1-6]="all OFF" (boot from 32bit flash, no boot sequence is used)
+ SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560)
+ SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode)
+ SW11[7]='ON' (rev2), 'OFF' (rev1)
+ SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector)
+ SW22[1-4]="OFF OFF ON OFF"
+ SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF"
+ J1 = "Enable Prog" (Make sure your flash is programmable for development)
+
+ If you want to test PCI functionality with a 33Mhz PCI card, you will
+ have to change the system clock from the default 66Mhz to 33Mhz by
+ setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need
+ double your platform clock(SW6) because the system clock is now only
+ half of its original value. For example, if at 66MHz your system
+ clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10.
+
+ SW17[8] ------+ SW6
+ SW15[1] ----+ | [0:1]
+ V V V V
+ 33MHz 1 1 1 0
+ 66MHz 0 0 0 1
+
+ Hmmm... That SW6 setting description is incomplete but it works.
+
+
+1.3 For the MPC85xxADS Rev A Board
+
+ As shipped, the board should be a 33MHz PCI bus with a CPU Clock
+ rate of 825 +/- fuzz:
+
+ Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
+
+ For 33MHz PCI, the switch settings should be like this:
+
+ SW18[7:1] = 0100001 = M==33 => 33MHz
+ SW18[8] = 1 => PWD Divider == 16
+ SW16[1:2] = 11 => N == 16 as PWD==1
+
+ Use the magical formula:
+ Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz
+
+ SW7[1:4] = 1010 = 10 => 10 x 33 = 330 CCB Sysclk
+ SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
+
+
+ For 66MHz PCI, the switch settings should be like this:
+
+ SW18[7:1] = 0100001 = M==33 => 33MHz
+ SW18[8] = 0 => PWD Divider == 1
+ SW16[1:2] = 01 => N == 8 as PWD == 0
+
+ Use the magical formula:
+ Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz
+
+ SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB Sysclk
+ SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
+
+ In order to use PCI-X (only in the first PCI slot. The one with
+ the RIO connector), you need to set SW1[4] (config) to 1 (off).
+ Also, configure the board to run PCI at 66 MHz.
+
+2. MEMORY MAP TO WORK WITH LINUX KERNEL
+
+2.1. For the initial bringup, we adopted a consistent memory scheme
+ between u-boot and linux kernel, you can customize it based on your
+ system requirements:
+
+ 0x0000_0000 0x7fff_ffff DDR 2G
+ 0x8000_0000 0x9fff_ffff PCI MEM 512M
+ 0xc000_0000 0xdfff_ffff Rapid IO 512M
+ 0xe000_0000 0xe00f_ffff CCSR 1M
+ 0xe200_0000 0xe2ff_ffff PCI IO 16M
+ 0xf000_0000 0xf7ff_ffff SDRAM 128M
+ 0xf800_0000 0xf80f_ffff BCSR 1M
+ 0xff00_0000 0xffff_ffff FLASH (boot bank) 16M
+
+2.2 We are submitting Linux kernel patches for MPC8540 and MPC8560. You
+ can download them from linuxppc-2.4 public source. Please make sure the
+ kernel's ppcboot.h is consistent with U-Boot's u-boot.h. You can use two
+ default configuration files as your starting points to configure the
+ kernel:
+ arch/powerpc/configs/mpc8540_ads_defconfig
+ arch/powerpc/configs/mpc8560_ads_defconfig
+
+3. DEFINITIONS AND COMPILATION
+
+3.1 Explanation on NEW definitions in:
+ include/configs/MPC8540ADS.h
+ include/configs/MPC8560ADS.h
+
+ CONFIG_BOOKE BOOKE(e.g. Motorola MPC85xx, AMCC 440, etc)
+ CONFIG_E500 BOOKE e500 family(Motorola)
+ CONFIG_MPC85xx MPC8540,MPC8560 and their derivatives
+ CONFIG_MPC8540 MPC8540 specific
+ CONFIG_MPC8540ADS MPC8540ADS board specific
+ CONFIG_MPC8560ADS MPC8560ADS board specific
+ CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet for networking
+ CONFIG_SPD_EEPROM Use SPD EEPROM for DDR auto configuration, you can
+ also manual config the DDR after undef this
+ definition.
+ CONFIG_DDR_ECC only for ECC DDR module
+ CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN DLL fix on some ADS boards needed
+ for more stability.
+ CONFIG_HAS_FEC If an FEC is on chip, set to 1, else 0.
+
+Other than the above definitions, the rest in the config files are
+straightforward.
+
+
+3.2 Compilation
+
+ Assuming you're using BASH shell:
+
+ export CROSS_COMPILE=your-cross-compile-prefix
+ cd u-boot
+ make distclean
+ make MPC8560ADS_config (or make MPC8540ADS_config)
+ make
+
+4. Notes:
+
+4.1 When connecting with kermit, the following commands must be present.in
+ your .kermrc file. These are especially important when booting as
+ MPC8560, as the serial console will not work without them:
+
+ set speed 115200
+ set carrier-watch off
+ set handshake none
+ set flow-control none
+ robust
+
+
+4.2 Sometimes after U-Boot is up, the 'tftp' won't work well with TSEC
+ ethernet. If that happens, you can try the following steps to make
+ network work:
+
+ MPC8560ADS>tftp 1000000 pImage
+ (if it hangs, use Ctrl-C to quit)
+ MPC8560ADS>nm fdf24524
+ >0
+ >1
+ >. (to quit this memory operation)
+ MPC8560ADS>tftp 1000000 pImage
+
+4.3 If you're one of the early developers using the Rev1 8540/8560 chips,
+ please use U-Boot 1.0.0, as the newer silicon will only support Rev2
+ and future revisions of 8540/8560.
+
+
+4.4 Reflash U-boot Image using U-boot
+
+ tftp 10000 u-boot.bin
+ protect off fff80000 ffffffff
+ erase fff80000 ffffffff
+ cp.b 10000 fff80000 80000
+
+
+4.5 Reflash U-Boot with a BDI-2000
+
+ BDI> erase 0xFFF80000 0x4000 0x20
+ BDI> prog 0xfff80000 u-boot.bin.8560ads
+ BDI> verify
+
+
+5. Screen dump MPC8540ADS board
+
+U-Boot 1.1.2(pq3-20040707-0) (Jul 6 2004 - 17:34:25)
+
+Freescale PowerPC
+ Core: E500, Version: 2.0, (0x80200020)
+ System: 8540, Version: 2.0, (0x80300020)
+ Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
+ L1 D-cache 32KB, L1 I-cache 32KB enabled.
+Board: ADS
+ PCI1: 32 bit, 66 MHz (compiled)
+I2C: ready
+DRAM: Initializing
+ SDRAM: 64 MB
+ DDR: 256 MB
+FLASH: 16 MB
+L2 cache enabled: 256KB
+*** Warning - bad CRC, using default environment
+
+In: serial
+Out: serial
+Err: serial
+Net: MOTO ENET0: PHY is Marvell 88E1011S (1410c62)
+MOTO ENET1: PHY is Marvell 88E1011S (1410c62)
+MOTO ENET2: PHY is Davicom DM9161E (181b881)
+MOTO ENET0, MOTO ENET1, MOTO ENET2
+Hit any key to stop autoboot: 0
+=>
+=> fli
+
+Bank # 1: Intel 28F640J3A (64 Mbit, 64 x 128K)
+ Size: 16 MB in 64 Sectors
+ Sector Start Addresses:
+ FF000000 FF040000 FF080000 FF0C0000 FF100000
+ FF140000 FF180000 FF1C0000 FF200000 FF240000
+ FF280000 FF2C0000 FF300000 FF340000 FF380000
+ FF3C0000 FF400000 FF440000 FF480000 FF4C0000
+ FF500000 FF540000 FF580000 FF5C0000 FF600000
+ FF640000 FF680000 FF6C0000 FF700000 FF740000
+ FF780000 FF7C0000 FF800000 FF840000 FF880000
+ FF8C0000 FF900000 FF940000 FF980000 FF9C0000
+ FFA00000 FFA40000 FFA80000 FFAC0000 FFB00000
+ FFB40000 FFB80000 FFBC0000 FFC00000 FFC40000
+ FFC80000 FFCC0000 FFD00000 FFD40000 FFD80000
+ FFDC0000 FFE00000 FFE40000 FFE80000 FFEC0000
+ FFF00000 FFF40000 FFF80000 (RO) FFFC0000 (RO)
+
+=> bdinfo
+memstart = 0x00000000
+memsize = 0x10000000
+flashstart = 0xFF000000
+flashsize = 0x01000000
+flashoffset = 0x00000000
+sramstart = 0x00000000
+sramsize = 0x00000000
+immr_base = 0xE0000000
+bootflags = 0xE4013F80
+intfreq = 825 MHz
+busfreq = 330 MHz
+ethaddr = 00:E0:0C:00:00:FD
+eth1addr = 00:E0:0C:00:01:FD
+eth2addr = 00:E0:0C:00:02:FD
+IP addr = 192.168.1.253
+baudrate = 115200 bps
+
+
+=> printenv
+bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
+ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;bootm $loadaddr $ramdiskaddr
+nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
+bootdelay=10
+baudrate=115200
+loads_echo=1
+ethaddr=00:E0:0C:00:00:FD
+eth1addr=00:E0:0C:00:01:FD
+eth2addr=00:E0:0C:00:02:FD
+ipaddr=192.168.1.253
+serverip=192.168.1.1
+rootpath=/nfsroot
+gatewayip=192.168.1.1
+netmask=255.255.255.0
+hostname=unknown
+bootfile=your.uImage
+loadaddr=200000
+netdev=eth0
+consoledev=ttyS0
+ramdiskaddr=400000
+ramdiskfile=your.ramdisk.u-boot
+stdin=serial
+stdout=serial
+stderr=serial
+ethact=MOTO ENET0
+
+Environment size: 1020/8188 bytes
diff --git a/marvell/uboot/doc/README.mpc85xxcds b/marvell/uboot/doc/README.mpc85xxcds
new file mode 100644
index 0000000..bc5db0c
--- /dev/null
+++ b/marvell/uboot/doc/README.mpc85xxcds
@@ -0,0 +1,225 @@
+Motorola MPC85xxCDS boards
+--------------------------
+
+The CDS family of boards consists of a PCI backplane called the
+"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot,
+and a CPU daughter card that bolts onto the daughter card.
+
+Much of the content of the README.mpc85xxads for the 85xx ADS boards
+applies to the 85xx CDS boards as well. In particular the toolchain,
+the switch nomenclature, and the basis for the memory map. There are
+some differences, though.
+
+
+Building U-Boot
+---------------
+
+The Binutils in current ELDK toolchain will not support MPC85xx
+chip. You need to use binutils-2.14.tar.bz2 (or newer) from
+ http://ftp.gnu.org/gnu/binutils.
+
+The 85xx CDS code base is known to compile using:
+ gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
+
+
+Memory Map
+----------
+
+The memory map for u-boot and linux has been extended w.r.t. the ADS
+platform to allow for utilization of all 85xx CDS devices. The memory
+map is setup for linux to operate properly. The linux source when
+configured for MPC85xx CDS has been updated to reflect the new memory
+map.
+
+The mapping is:
+
+ 0x0000_0000 0x7fff_ffff DDR 2G
+ 0x8000_0000 0x9fff_ffff PCI1 MEM 512M
+ 0xa000_0000 0xbfff_ffff PCI2 MEM 512M
+ 0xe000_0000 0xe00f_ffff CCSR 1M
+ 0xe200_0000 0xe2ff_ffff PCI1 IO 16M
+ 0xe300_0000 0xe3ff_ffff PCI2 IO 16M
+ 0xf000_0000 0xf7ff_ffff SDRAM 128M
+ 0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M
+ 0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M
+ 0xff80_0000 0xffff_ffff FLASH (boot bank) 8M
+
+ (*) The system control registers (CADMUS) start at offset 0xfdb0_4000
+ within the NVRAM/CADMUS region of memory.
+
+
+Using Flash
+-----------
+
+The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000).
+There is a switch which allows the boot-bank to be selected. The switch
+settings for updating flash are given below.
+
+The u-boot commands for copying the boot-bank into the secondary bank are
+as follows:
+
+ erase ff780000 ff7fffff
+ cp.b fff80000 ff780000 80000
+
+
+U-boot/kermit commands for downloading an image, then copying
+it into the secondary bank:
+
+ loadb
+ [Drop to kermit:
+ ^\c
+ send <u-boot-bin-image>
+ c
+ ]
+
+ erase ff780000 ff7fffff
+ cp.b $loadaddr ff780000 80000
+
+
+U-boot commands for downloading an image via tftp and flashing
+it into the second bank:
+
+ tftp 10000 <u-boot.bin.image>
+ erase ff780000 ff7fffff
+ cp.b 10000 ff780000 80000
+
+
+After copying the image into the second bank of flash, be sure to toggle
+SW2[2] on the carrier card before resetting the board in order to set the
+secondary bank as the boot-bank.
+
+
+Carrier Board Switches
+----------------------
+
+As a reminder, you should read the README.mpc85xxads too.
+
+Most switches on the carrier board should not be changed. The only
+user-settable switches on the carrier board are used to configure
+the flash banks and determining the PCI slot.
+
+The first two bits of SW2 control how flash is used on the board:
+
+ 12345678
+ --------
+ SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available.
+ 01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped).
+ 10XXXXXX FLASH: Boot promjet, bank 1 available
+ 11XXXXXX FLASH: Boot promjet, bank 2 available
+
+The boot bank is always mapped to FF80_0000 and listed first by
+the "flinfo" command. The secondary bank is always FF00_0000.
+
+When using PCI, linux needs to know to which slot the CDS carrier is
+connected.. By convention, the user-specific bits of SW2 are used to
+convey this information:
+
+ 12345678
+ --------
+ SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia
+ xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia
+ xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia
+ xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia
+
+These are cleverly, er, clearly silkscreened as Slot 1 through 4,
+respectively, on the Arcadia near the support posts.
+
+
+The default setting of all switches on the carrier board is:
+
+ 12345678
+ --------
+ SW1=01101100
+ SW2=0x1111yy x=Flash bank, yy=PCI slot
+ SW3=11101111
+ SW4=10001000
+
+
+8555/41 CPU Card Switches
+-------------------------
+
+Most switches on the CPU Card should not be changed. However, the
+frequency can be changed by setting SW3:
+
+ 12345678
+ --------
+ SW3=XX00XXXX == CORE:CCB 2:1
+ XX01XXXX == CORE:CCB 5:2
+ XX10XXXX == CORE:CCB 3:1
+ XX11XXXX == CORE:CCB 7:2
+ XXXX1000 == CCB:SYSCLK 8:1
+ XXXX1010 == CCB:SYSCLK 10:1
+
+A safe default setting for all switches on the CPU board is:
+
+ 12345678
+ --------
+ SW1=10001111
+ SW2=01000111
+ SW3=00001000
+ SW4=11111110
+
+
+8548 CPU Card Switches
+----------------------
+And, just to be confusing, in this set of switches:
+
+ ON = 1
+ OFF = 0
+
+Default
+ SW1=11111101
+ SW2=10011111
+ SW3=11001000 (8X) (2:1)
+ SW4=11110011
+
+ SW3=X000XXXX == CORE:CCB 4:1
+ X001XXXX == CORE:CCB 9:2
+ X010XXXX == CORE:CCB 1:1
+ X011XXXX == CORE:CCB 3:2
+ X100XXXX == CORE:CCB 2:1
+ X101XXXX == CORE:CCB 5:2
+ X110XXXX == CORE:CCB 3:1
+ X111XXXX == CORE:CCB 7:2
+ XXXX0000 == CCB:SYSCLK 16:1
+ XXXX0001 == RESERVED
+ XXXX0010 == CCB:SYSCLK 2:1
+ XXXX0011 == CCB:SYSCLK 3:1
+ XXXX0100 == CCB:SYSCLK 4:1
+ XXXX0101 == CCB:SYSCLK 5:1
+ XXXX0110 == CCB:SYSCLK 6:1
+ XXXX0111 == RESERVED
+ XXXX1000 == CCB:SYSCLK 8:1
+ XXXX1001 == CCB:SYSCLK 9:1
+ XXXX1010 == CCB:SYSCLK 10:1
+ XXXX1011 == RESERVED
+ XXXX1100 == CCB:SYSCLK 12:1
+ XXXX1101 == CCB:SYSCLK 20:1
+ XXXX1110 == RESERVED
+ XXXX1111 == RESERVED
+
+
+eDINK Info
+----------
+
+One bank of flash may contain an eDINK image.
+
+Memory Map:
+
+ CCSRBAR @ 0xe0000000
+ Flash Bank 1 @ 0xfe000000
+ Flash Bank 2 @ 0xff000000
+ Ram @ 0
+
+Commands for downloading a u-boot image to memory from edink:
+
+ env -c
+ time -s 4/8/2004 4:30p
+ dl -k -b -o 100000
+ [Drop to kermit:
+ ^\c
+ transmit /binary <u-boot-bin-image>
+ c
+ ]
+
+ fu -l 100000 fe780000 80000
diff --git a/marvell/uboot/doc/README.mxc_hab b/marvell/uboot/doc/README.mxc_hab
new file mode 100644
index 0000000..43e64a2
--- /dev/null
+++ b/marvell/uboot/doc/README.mxc_hab
@@ -0,0 +1,48 @@
+High Assurance Boot (HAB) for i.MX6 CPUs
+
+To authenticate U-Boot only by the CPU there is no code required in
+U-Boot itself. However, the U-Boot image to be programmed into the
+boot media needs to be properly constructed, i.e. it must contain a
+proper Command Sequence File (CSF).
+
+The Initial Vector Table contains a pointer to the CSF. Please see
+doc/README.imximage for how to prepare u-boot.imx.
+
+The CSF itself is being generated by Freescale HAB tools.
+
+mkimage will output additional information about "HAB Blocks"
+which can be used in the Freescale tooling to authenticate U-Boot
+(entries in the CSF file).
+
+Image Type: Freescale IMX Boot Image
+Image Ver: 2 (i.MX53/6 compatible)
+Data Size: 327680 Bytes = 320.00 kB = 0.31 MB
+Load Address: 177ff420
+Entry Point: 17800000
+HAB Blocks: 177ff400 00000000 0004dc00
+ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
+ | | |
+ | | -------- (1)
+ | |
+ | ------------------- (2)
+ |
+ --------------------------- (3)
+
+(1) Size of area in file u-boot.imx to sign
+ This area should include the IVT, the Boot Data the DCD
+ and U-Boot itself.
+(2) Start of area in u-boot.imx to sign
+(3) Start of area in RAM to authenticate
+
+CONFIG_SECURE_BOOT currently enables only an additional command
+'hab_status' in U-Boot to retrieve the HAB status and events. This
+can be useful while developing and testing HAB.
+
+Commands to generate a signed U-Boot using Freescale HAB tools:
+cst --o U-Boot_CSF.bin < U-Boot.CSF
+objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 \
+ U-Boot_CSF.bin U-Boot_CSF_pad.bin
+cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx
+
+NOTE: U-Boot_CSF.bin needs to be padded to the value specified in
+the imximage.cfg file.
diff --git a/marvell/uboot/doc/README.mxc_ocotp b/marvell/uboot/doc/README.mxc_ocotp
new file mode 100644
index 0000000..7a2863c
--- /dev/null
+++ b/marvell/uboot/doc/README.mxc_ocotp
@@ -0,0 +1,51 @@
+Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP)
+on MXC
+
+This IP can be found on the following SoCs:
+ - Vybrid VF610,
+ - i.MX6.
+
+Note that this IP is different from albeit similar to the IPs of the same name
+that can be found on the following SoCs:
+ - i.MX23,
+ - i.MX28,
+ - i.MX50.
+
+The section numbers in this file refer to the i.MX6 Reference Manual.
+
+A fuse word contains 32 fuse bit slots, as explained in 46.2.1.
+
+A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the
+memory map in 46.4.
+
+Some fuse bit or word slots may not have the corresponding fuses actually
+implemented in the fusebox.
+
+See the README files of the SoCs using this driver in order to know the
+conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
+addresses.
+
+Fuse operations:
+
+ Read
+ Read operations are implemented as read accesses to the shadow registers,
+ using "Bankx Wordy" from the memory map in 46.4. This is explained in
+ detail by the first two paragraphs in 46.2.1.2.
+
+ Sense
+ Sense operations are implemented as the direct fusebox read explained by
+ the steps in 46.2.1.2.
+
+ Program
+ Program operations are implemented as explained by the steps in 46.2.1.3.
+ Following this operation, the shadow registers are not reloaded by the
+ hardware.
+
+ Override
+ Override operations are implemented as write accesses to the shadow
+ registers, as explained by the first paragraph in 46.2.1.3.
+
+Configuration:
+
+ CONFIG_MXC_OCOTP
+ Define this to enable the mxc_ocotp driver.
diff --git a/marvell/uboot/doc/README.mxs b/marvell/uboot/doc/README.mxs
new file mode 100644
index 0000000..0235a5a
--- /dev/null
+++ b/marvell/uboot/doc/README.mxs
@@ -0,0 +1,264 @@
+Booting U-boot on a MXS processor
+=================================
+
+This document describes the MXS U-Boot port. This document mostly covers topics
+related to making the module/board bootable.
+
+Terminology
+-----------
+
+The term "MXS" refers to a family of Freescale SoCs that is composed by MX23
+and MX28.
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be typed
+into the unix command prompt in U-Boot source code root directory.
+
+The (=>) introduces a snipped of code that should by typed into U-Boot command
+prompt
+
+Contents
+--------
+
+1) Prerequisites
+2) Compiling U-Boot for a MXS based board
+3) Installation of U-Boot for a MXS based board to SD card
+4) Installation of U-Boot into NAND flash on a MX28 based board
+
+1) Prerequisites
+----------------
+
+To make a MXS based board bootable, some tools are necessary. The only
+mandatory tool is the "mxsboot" tool found in U-Boot source tree. The
+tool is built automatically when compiling U-Boot for i.MX23 or i.MX28.
+
+The production of BootStream image is handled via "mkimage", which is
+also part of the U-Boot source tree. The "mkimage" requires OpenSSL
+development libraries to be installed. In case of Debian and derivates,
+this is installed by running:
+
+ $ sudo apt-get install libssl-dev
+
+NOTE: The "elftosb" tool distributed by Freescale Semiconductor is no
+ longer necessary for general use of U-Boot on i.MX23 and i.MX28.
+ The mkimage supports generation of BootStream images encrypted
+ with a zero key, which is the vast majority of use-cases. In
+ case you do need to produce image encrypted with non-zero key
+ or other special features, please use the "elftosb" tool,
+ otherwise continue to section 2). The installation procedure of
+ the "elftosb" is outlined below:
+
+Firstly, obtain the elftosb archive from the following location:
+
+ ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is "10.12.01". To obtain the file from command
+line, use:
+
+ $ VER="10.12.01"
+ $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+ $ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+ $ cd elftosb-${VER}/
+ $ make LIBS="-lstdc++ -lm" elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+ $ strip bld/linux/elftosb
+
+Finally, install the "elftosb" binary. The "install" target is missing, so just
+copy the binary by hand:
+
+ $ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the "elftosb" binary can be found in your $PATH, in this case this
+means "/usr/local/bin/" has to be in your $PATH.
+
+2) Compiling U-Boot for a MXS based board
+-------------------------------------------
+
+Compiling the U-Boot for a MXS board is straightforward and done as compiling
+U-Boot for any other ARM device. For cross-compiler setup, please refer to
+ELDK5.0 documentation. First, clean up the source code:
+
+ $ make mrproper
+
+Next, configure U-Boot for a MXS based board
+
+ $ make <mxs_based_board_name>_config
+
+Examples:
+
+1. For building U-boot for Denx M28EVK board:
+
+ $ make m28evk_config
+
+2. For building U-boot for Freescale MX28EVK board:
+
+ $ make mx28evk_config
+
+3. For building U-boot for Freescale MX23EVK board:
+
+ $ make mx23evk_config
+
+4. For building U-boot for Olimex MX23 Olinuxino board:
+
+ $ make mx23_olinuxino_config
+
+Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a special
+type of file, which MXS CPUs can boot. This is handled by the following
+command:
+
+ $ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -j<N>, where N is number of
+ compiler instances that'll run in parallel.
+
+The code produces "u-boot.sb" file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header is
+discussed in the following chapters.
+
+NOTE: The process that produces u-boot.sb uses the mkimage to generate the
+ BootStream. The BootStream is encrypted with zero key. In case you need
+ some special features of the BootStream and plan on using the "elftosb"
+ tool instead, the invocation to produce a compatible BootStream with the
+ one produced by mkimage is outlined below. For further details, refer to
+ the documentation bundled with the "elftosb" package.
+
+ $ elftosb -zf imx23 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd \
+ -o u-boot.sb
+ $ elftosb -zf imx28 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd \
+ -o u-boot.sb
+
+3) Installation of U-Boot for a MXS based board to SD card
+----------------------------------------------------------
+
+To boot a MXS based board from SD, set the boot mode DIP switches according to
+to MX28 manual, section 12.2.1 (Table 12-2) or MX23 manual, section 35.1.2
+(Table 35-3).
+
+The SD card used to boot U-Boot must contain a DOS partition table, which in
+turn carries a partition of special type and which contains a special header.
+The rest of partitions in the DOS partition table can be used by the user.
+
+To prepare such partition, use your favourite partitioning tool. The partition
+must have the following parameters:
+
+ * Start sector .......... sector 2048
+ * Partition size ........ at least 1024 kb
+ * Partition type ........ 0x53 (sometimes "OnTrack DM6 Aux3")
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure to
+run fdisk with the option "-u=sectors" to set units to sectors:
+
+ * o ..................... create a clear partition table
+ * n ..................... create new partition
+ * p ............. primary partition
+ * 1 ............. first partition
+ * 2048 .......... first sector is 2048
+ * +1M ........... make the partition 1Mb big
+ * t 1 ................... change first partition ID
+ * 53 ............ change the ID to 0x53 (OnTrack DM6 Aux3)
+ * <create other partitions>
+ * w ..................... write partition table to disk
+
+The partition layout is ready, next the special partition must be filled with
+proper contents. The contents is generated by running the following command
+(see chapter 2)):
+
+ $ ./tools/mxsboot sd u-boot.sb u-boot.sd
+
+The resulting file, "u-boot.sd", shall then be written to the partition. In this
+case, we assume the first partition of the SD card is /dev/mmcblk0p1:
+
+ $ dd if=u-boot.sd of=/dev/mmcblk0p1
+
+Last step is to insert the card into the MXS based board and boot.
+
+NOTE: If the user needs to adjust the start sector, the "mxsboot" tool contains
+ a "-p" switch for that purpose. The "-p" switch takes the sector number as
+ an argument.
+
+4) Installation of U-Boot into NAND flash on a MX28 based board
+---------------------------------------------------------------
+
+To boot a MX28 based board from NAND, set the boot mode DIP switches according
+to MX28 manual section 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V.
+
+There are two possibilities when preparing an image writable to NAND flash.
+
+ I) The NAND wasn't written at all yet or the BCB is broken
+ ----------------------------------------------------------
+ In this case, both BCB (FCB and DBBT) and firmware needs to be
+ written to NAND. To generate NAND image containing all these,
+ there is a tool called "mxsboot" in the "tools/" directory. The tool
+ is invoked on "u-boot.sb" file from chapter 2):
+
+ $ ./tools/mxsboot nand u-boot.sb u-boot.nand
+
+ NOTE: The above invokation works for NAND flash with geometry of
+ 2048b per page, 64b OOB data, 128kb erase size. If your chip
+ has a different geometry, please use:
+
+ -w <size> change page size (default 2048 b)
+ -o <size> change oob size (default 64 b)
+ -e <size> change erase size (default 131072 b)
+
+ The geometry information can be obtained from running U-Boot
+ on the MX28 board by issuing the "nand info" command.
+
+ The resulting file, "u-boot.nand" can be written directly to NAND
+ from the U-Boot prompt. To simplify the process, the U-Boot default
+ environment contains script "update_nand_full" to update the system.
+
+ This script expects a working TFTP server containing the file
+ "u-boot.nand" in it's root directory. This can be changed by
+ adjusting the "update_nand_full_filename" varible.
+
+ To update the system, run the following in U-Boot prompt:
+
+ => run update_nand_full
+
+ In case you would only need to update the bootloader in future,
+ see II) below.
+
+ II) The NAND was already written with a good BCB
+ ------------------------------------------------
+ This part applies after the part I) above was done at least once.
+
+ If part I) above was done correctly already, there is no need to
+ write the FCB and DBBT parts of NAND again. It's possible to upgrade
+ only the bootloader image.
+
+ To simplify the process of firmware update, the U-Boot default
+ environment contains script "update_nand_firmware" to update only
+ the firmware, without rewriting FCB and DBBT.
+
+ This script expects a working TFTP server containing the file
+ "u-boot.sb" in it's root directory. This can be changed by
+ adjusting the "update_nand_firmware_filename" varible.
+
+ To update the system, run the following in U-Boot prompt:
+
+ => run update_nand_firmware
+
+ III) Special settings for the update scripts
+ --------------------------------------------
+ There is a slight possibility of the user wanting to adjust the
+ STRIDE and COUNT options of the NAND boot. For description of these,
+ see MX28 manual section 12.12.1.2 and 12.12.1.3.
+
+ The update scripts take this possibility into account. In case the
+ user changes STRIDE by blowing fuses, the user also has to change
+ "update_nand_stride" variable. In case the user changes COUNT by
+ blowing fuses, the user also has to change "update_nand_count"
+ variable for the update scripts to work correctly.
+
+ In case the user needs to boot a firmware image bigger than 1Mb, the
+ user has to adjust the "update_nand_firmware_maxsz" variable for the
+ update scripts to work properly.
diff --git a/marvell/uboot/doc/README.mxsimage b/marvell/uboot/doc/README.mxsimage
new file mode 100644
index 0000000..0d31cba
--- /dev/null
+++ b/marvell/uboot/doc/README.mxsimage
@@ -0,0 +1,165 @@
+Freescale i.MX233/i.MX28 SB image generator via mkimage
+=======================================================
+
+This tool allows user to produce SB BootStream encrypted with a zero key.
+Such a BootStream is then bootable on i.MX23/i.MX28.
+
+Usage -- producing image:
+=========================
+The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
+To generate an image, write an image configuration file and run:
+
+ mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
+ <output bootstream file>
+
+The output bootstream file is usually using the .sb file extension. Note
+that the example configuration files for producing bootable BootStream with
+the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/
+directory. See the following files:
+
+ mxsimage.mx23.cfg -- This is an example configuration for i.MX23
+ mxsimage.mx28.cfg -- This is an example configuration for i.MX28
+
+Each configuration file uses very simple instruction semantics and a few
+additional rules have to be followed so that a useful image can be produced.
+These semantics and rules will be outlined now.
+
+- Each line of the configuration file contains exactly one instruction.
+- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
+- The configuration file is a concatenation of blocks called "sections" and
+ optionally "DCD blocks" (see below).
+ - Each "section" is started by the "SECTION" instruction.
+ - The "SECTION" instruction has the following semantics:
+
+ SECTION u32_section_number [BOOTABLE]
+ - u32_section_number :: User-selected ID of the section
+ - BOOTABLE :: Sets the section as bootable
+
+ - A bootable section is one from which the BootROM starts executing
+ subsequent instructions or code. Exactly one section must be selected
+ as bootable, usually the one containing the instructions and data to
+ load the bootloader.
+
+ - A "SECTION" must be immediatelly followed by a "TAG" instruction.
+ - The "TAG" instruction has the following semantics:
+
+ TAG [LAST]
+ - LAST :: Flag denoting the last section in the file
+
+ - After a "TAG" unstruction, any of the following instructions may follow
+ in any order and any quantity:
+
+ NOOP
+ - This instruction does nothing
+
+ LOAD u32_address string_filename
+ - Instructs the BootROM to load file pointed by "string_filename" onto
+ address "u32_address".
+
+ LOAD IVT u32_address u32_IVT_entry_point
+ - Crafts and loads IVT onto address "u32_address" with the entry point
+ of u32_IVT_entry_point.
+ - i.MX28-specific instruction!
+
+ LOAD DCD u32_address u32_DCD_block_ID
+ - Loads the DCD block with ID "u32_DCD_block_ID" onto address
+ "u32_address" and executes the contents of this DCD block
+ - i.MX28-specific instruction!
+
+ FILL u32_address u32_pattern u32_length
+ - Starts to write memory from addres "u32_address" with a pattern
+ specified by "u32_pattern". Writes exactly "u32_length" bytes of the
+ pattern.
+
+ JUMP [HAB] u32_address [u32_r0_arg]
+ - Jumps onto memory address specified by "u32_address" by setting this
+ address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
+ register "r0" to the executed code if this option is specified.
+ Otherwise, ARM register "r0" will default to value 0x00000000. The
+ optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
+
+ CALL [HAB] u32_address [u32_r0_arg]
+ - See JUMP instruction above, as the operation is exactly the same with
+ one difference. The CALL instruction does allow returning into the
+ BootROM from the executed code. U-Boot makes use of this in it's SPL
+ code.
+
+ MODE string_mode
+ - Restart the CPU and start booting from device specified by the
+ "string_mode" argument. The "string_mode" differs for each CPU
+ and can be:
+ i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
+ JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
+ i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
+ JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
+
+ - An optional "DCD" blocks can be added at the begining of the configuration
+ file. Note that the DCD is only supported on i.MX28.
+ - The DCD blocks must be inserted before the first "section" in the
+ configuration file.
+ - The DCD block has the following semantics:
+
+ DCD u32_DCD_block_ID
+ - u32_DCD_block_ID :: The ID number of the DCD block, must match
+ the ID number used by "LOAD DCD" instruction.
+
+ - The DCD block must be followed by one of the following instructions. All
+ of the instructions operate either on 1, 2 or 4 bytes. This is selected by
+ the 'n' suffix of the instruction:
+
+ WRITE.n u32_address u32_value
+ - Write the "u32_value" to the "u32_address" address.
+
+ ORR.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-OR with the "u32_value" and
+ write the result back to "u32_address".
+
+ ANDC.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-AND with the complement of
+ "u32_value" and write the result back to "u32_address".
+
+ EQZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is zero. If it is, break the loop earlier.
+
+ NEZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is non-zero. If it is, break the loop earlier.
+
+ EQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" equals the "u32_mask". If the values are equal, break the
+ reading loop.
+
+ NEQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" does not equal the "u32_mask". If the values are not equal,
+ break the reading loop.
+
+ NOOP
+ - This instruction does nothing.
+
+- If the verbose output from the BootROM is enabled, the BootROM will produce a
+ letter on the Debug UART for each instruction it started processing. Here is a
+ mapping between the above instructions and the BootROM verbose output:
+
+ H -- SB Image header loaded
+ T -- TAG instruction
+ N -- NOOP instruction
+ L -- LOAD instruction
+ F -- FILL instruction
+ J -- JUMP instruction
+ C -- CALL instruction
+ M -- MODE instruction
+
+Usage -- verifying image:
+=========================
+
+The mxsimage can also verify and dump contents of an image. Use the following
+syntax to verify and dump contents of an image:
+
+ mkimage -l <input bootstream file>
+
+This will output all the information from the SB image header and all the
+instructions contained in the SB image. It will also check if the various
+checksums in the SB image are correct.
diff --git a/marvell/uboot/doc/README.nand b/marvell/uboot/doc/README.nand
new file mode 100644
index 0000000..b91f198
--- /dev/null
+++ b/marvell/uboot/doc/README.nand
@@ -0,0 +1,303 @@
+NAND FLASH commands and notes
+
+See NOTE below!!!
+
+# (C) Copyright 2003
+# Dave Ellis, SIXNET, dge@sixnetio.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+Commands:
+
+ nand bad
+ Print a list of all of the bad blocks in the current device.
+
+ nand device
+ Print information about the current NAND device.
+
+ nand device num
+ Make device `num' the current device and print information about it.
+
+ nand erase off|partition size
+ nand erase clean [off|partition size]
+ Erase `size' bytes starting at offset `off'. Alternatively partition
+ name can be specified, in this case size will be eventually limited
+ to not exceed partition size (this behaviour applies also to read
+ and write commands). Only complete erase blocks can be erased.
+
+ If `erase' is specified without an offset or size, the entire flash
+ is erased. If `erase' is specified with partition but without an
+ size, the entire partition is erased.
+
+ If `clean' is specified, a JFFS2-style clean marker is written to
+ each block after it is erased.
+
+ This command will not erase blocks that are marked bad. There is
+ a debug option in cmd_nand.c to allow bad blocks to be erased.
+ Please read the warning there before using it, as blocks marked
+ bad by the manufacturer must _NEVER_ be erased.
+
+ nand info
+ Print information about all of the NAND devices found.
+
+ nand read addr ofs|partition size
+ Read `size' bytes from `ofs' in NAND flash to `addr'. Blocks that
+ are marked bad are skipped. If a page cannot be read because an
+ uncorrectable data error is found, the command stops with an error.
+
+ nand read.oob addr ofs|partition size
+ Read `size' bytes from the out-of-band data area corresponding to
+ `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of
+ data for one 512-byte page or 2 256-byte pages. There is no check
+ for bad blocks or ECC errors.
+
+ nand write addr ofs|partition size
+ Write `size' bytes from `addr' to `ofs' in NAND flash. Blocks that
+ are marked bad are skipped. If a page cannot be read because an
+ uncorrectable data error is found, the command stops with an error.
+
+ As JFFS2 skips blocks similarly, this allows writing a JFFS2 image,
+ as long as the image is short enough to fit even after skipping the
+ bad blocks. Compact images, such as those produced by mkfs.jffs2
+ should work well, but loading an image copied from another flash is
+ going to be trouble if there are any bad blocks.
+
+ nand write.trimffs addr ofs|partition size
+ Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to
+ the NAND flash in a manner identical to the 'nand write' command
+ described above -- with the additional check that all pages at the end
+ of eraseblocks which contain only 0xff data will not be written to the
+ NAND flash. This behaviour is required when flashing UBI images
+ containing UBIFS volumes as per the UBI FAQ[1].
+
+ [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
+
+ nand write.oob addr ofs|partition size
+ Write `size' bytes from `addr' to the out-of-band data area
+ corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
+ of data for one 512-byte page or 2 256-byte pages. There is no check
+ for bad blocks.
+
+ nand read.raw addr ofs|partition [count]
+ nand write.raw addr ofs|partition [count]
+ Read or write one or more pages at "ofs" in NAND flash, from or to
+ "addr" in memory. This is a raw access, so ECC is avoided and the
+ OOB area is transferred as well. If count is absent, it is assumed
+ to be one page. As with .yaffs2 accesses, the data is formatted as
+ a packed sequence of "data, oob, data, oob, ..." -- no alignment of
+ individual pages is maintained.
+
+Configuration Options:
+
+ CONFIG_CMD_NAND
+ Enables NAND support and commmands.
+
+ CONFIG_CMD_NAND_TORTURE
+ Enables the torture command (see description of this command below).
+
+ CONFIG_MTD_NAND_ECC_JFFS2
+ Define this if you want the Error Correction Code information in
+ the out-of-band data to be formatted to match the JFFS2 file system.
+ CONFIG_MTD_NAND_ECC_YAFFS would be another useful choice for
+ someone to implement.
+
+ CONFIG_SYS_MAX_NAND_DEVICE
+ The maximum number of NAND devices you want to support.
+
+ CONFIG_SYS_NAND_MAX_ECCPOS
+ If specified, overrides the maximum number of ECC bytes
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 48 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_OOBFREE
+ If specified, overrides the maximum number of free OOB regions
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 2 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_CHIPS
+ The maximum number of NAND chips per device to be supported.
+
+ CONFIG_SYS_NAND_SELF_INIT
+ Traditionally, glue code in drivers/mtd/nand/nand.c has driven
+ the initialization process -- it provides the mtd and nand
+ structs, calls a board init function for a specific device,
+ calls nand_scan(), and registers with mtd.
+
+ This arrangement does not provide drivers with the flexibility to
+ run code between nand_scan_ident() and nand_scan_tail(), or other
+ deviations from the "normal" flow.
+
+ If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/nand.c
+ will make one call to board_nand_init(), with no arguments. That
+ function is responsible for calling a driver init function for
+ each NAND device on the board, that performs all initialization
+ tasks except setting mtd->name, and registering with the rest of
+ U-Boot. Those last tasks are accomplished by calling nand_register()
+ on the new mtd device.
+
+ Example of new init to be added to the end of an existing driver
+ init:
+
+ /*
+ * devnum is the device number to be used in nand commands
+ * and in mtd->name. Must be less than
+ * CONFIG_SYS_NAND_MAX_DEVICE.
+ */
+ mtd = &nand_info[devnum];
+
+ /* chip is struct nand_chip, and is now provided by the driver. */
+ mtd->priv = &chip;
+
+ /*
+ * Fill in appropriate values if this driver uses these fields,
+ * or uses the standard read_byte/write_buf/etc. functions from
+ * nand_base.c that use these fields.
+ */
+ chip.IO_ADDR_R = ...;
+ chip.IO_ADDR_W = ...;
+
+ if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
+ error out
+
+ /*
+ * Insert here any code you wish to run after the chip has been
+ * identified, but before any other I/O is done.
+ */
+
+ if (nand_scan_tail(mtd))
+ error out
+
+ if (nand_register(devnum))
+ error out
+
+ In addition to providing more flexibility to the driver, it reduces
+ the difference between a U-Boot driver and its Linux counterpart.
+ nand_init() is now reduced to calling board_nand_init() once, and
+ printing a size summary. This should also make it easier to
+ transition to delayed NAND initialization.
+
+ Please convert your driver even if you don't need the extra
+ flexibility, so that one day we can eliminate the old mechanism.
+
+
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
+
+ CONFIG_BCH
+ Enables software based BCH ECC algorithm present in lib/bch.c
+ This is used by SoC platforms which do not have built-in ELM
+ hardware engine required for BCH ECC correction.
+
+
+Platform specific options
+=========================
+ CONFIG_NAND_OMAP_GPMC
+ Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms.
+ GPMC controller is used for parallel NAND flash devices, and can
+ do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8
+ and BCH16 ECC algorithms.
+
+ CONFIG_NAND_OMAP_ELM
+ Enables omap_elm.c driver for OMAPx and AMxxxx platforms.
+ ELM controller is used for ECC error detection (not ECC calculation)
+ of BCH4, BCH8 and BCH16 ECC algorithms.
+ Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
+ thus such SoC platforms need to depend on software library for ECC error
+ detection. However ECC calculation on such plaforms would still be
+ done by GPMC controller.
+
+ CONFIG_NAND_OMAP_ECCSCHEME
+ On OMAP platforms, this CONFIG specifies NAND ECC scheme.
+ It can take following values:
+ OMAP_ECC_HAM1_CODE_SW
+ 1-bit Hamming code using software lib.
+ (for legacy devices only)
+ OMAP_ECC_HAM1_CODE_HW
+ 1-bit Hamming code using GPMC hardware.
+ (for legacy devices only)
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH4_CODE_HW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using software library.
+ - requires CONFIG_BCH to enable software BCH library
+ (For legacy device which do not have ELM h/w engine)
+ OMAP_ECC_BCH8_CODE_HW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using ELM hardware engine.
+
+NOTE:
+=====
+
+The current NAND implementation is based on what is in recent
+Linux kernels. The old legacy implementation has been removed.
+
+If you have board code which used CONFIG_NAND_LEGACY, you'll need
+to convert to the current NAND interface for it to continue to work.
+
+The Disk On Chip driver is currently broken and has been for some time.
+There is a driver in drivers/mtd/nand, taken from Linux, that works with
+the current NAND system but has not yet been adapted to the u-boot
+environment.
+
+Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
+
+JFFS2 related commands:
+
+ implement "nand erase clean" and old "nand erase"
+ using both the new code which is able to skip bad blocks
+ "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob.
+
+Miscellaneous and testing commands:
+ "markbad [offset]"
+ create an artificial bad block (for testing bad block handling)
+
+ "scrub [offset length]"
+ like "erase" but don't skip bad block. Instead erase them.
+ DANGEROUS!!! Factory set bad blocks will be lost. Use only
+ to remove artificial bad blocks created with the "markbad" command.
+
+ "torture offset"
+ Torture block to determine if it is still reliable.
+ Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
+ This command returns 0 if the block is still reliable, else 1.
+ If the block is detected as unreliable, it is up to the user to decide to
+ mark this block as bad.
+ The analyzed block is put through 3 erase / write cycles (or less if the block
+ is detected as unreliable earlier).
+ This command can be used in scripts, e.g. together with the markbad command to
+ automate retries and handling of possibly newly detected bad blocks if the
+ nand write command fails.
+ It can also be used manually by users having seen some NAND errors in logs to
+ search the root cause of these errors.
+ The underlying nand_torture() function is also useful for code willing to
+ automate actions following a nand->write() error. This would e.g. be required
+ in order to program or update safely firmware to NAND, especially for the UBI
+ part of such firmware.
+
+
+NAND locking command (for chips with active LOCKPRE pin)
+
+ "nand lock"
+ set NAND chip to lock state (all pages locked)
+
+ "nand lock tight"
+ set NAND chip to lock tight state (software can't change locking anymore)
+
+ "nand lock status"
+ displays current locking status of all pages
+
+ "nand unlock [offset] [size]"
+ unlock consecutive area (can be called multiple times for different areas)
+
+ "nand unlock.allexcept [offset] [size]"
+ unlock all except specified consecutive area
+
+I have tested the code with board containing 128MiB NAND large page chips
+and 32MiB small page chips.
diff --git a/marvell/uboot/doc/README.nand-boot-ppc440 b/marvell/uboot/doc/README.nand-boot-ppc440
new file mode 100644
index 0000000..1e9c102
--- /dev/null
+++ b/marvell/uboot/doc/README.nand-boot-ppc440
@@ -0,0 +1,60 @@
+-----------------------------
+NAND boot on PPC440 platforms
+-----------------------------
+
+This document describes the U-Boot NAND boot feature as it
+is implemented for the AMCC Sequoia (PPC440EPx) board.
+
+The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH,
+completely without NOR FLASH. This can be done by using the NAND
+boot feature of the 440 NAND flash controller (NDFC).
+
+Here a short description of the different boot stages:
+
+a) IPL (Initial Program Loader, integrated inside CPU)
+------------------------------------------------------
+Will load first 4k from NAND (SPL) into cache and execute it from there.
+
+b) SPL (Secondary Program Loader)
+---------------------------------
+Will load special U-Boot version (NUB) from NAND and execute it. This SPL
+has to fit into 4kByte. It sets up the CPU and configures the SDRAM
+controller and the NAND controller so that the special U-Boot image can be
+loaded from NAND to SDRAM.
+This special image is build in the directory "nand_spl".
+
+c) NUB (NAND U-Boot)
+--------------------
+This NAND U-Boot (NUB) is a special U-Boot version which can be started
+from RAM. Therefore it mustn't (re-)configure the SDRAM controller.
+
+On 440EPx the SPL is copied to internal SRAM before the NAND controller
+is set up. While still running from cache, I experienced problems accessing
+the NAND controller.
+
+
+Example: Build and install NAND boot image for Sequoia (440EPx):
+
+a) Configure for sequoia with NAND boot support:
+# make sequoia_nand_config
+
+b) Build image(s)
+# make
+
+This will generate the SPL image in the "nand_spl" directory:
+nand_spl/u-boot-spl.bin
+Also another image is created spanning a whole NAND block (16kBytes):
+nand_spl/u-boot-spl-16k.bin
+The main NAND U-Boot image is generated in the toplevel directory:
+u-boot.bin
+A combined image of u-boot-spl-16k.bin and u-boot.bin is also created:
+u-boot-nand.bin
+
+This image should be programmed at offset 0 in the NAND flash:
+
+# tftp 100000 /tftpboot/sequoia/u-boot-nand.bin
+# nand erase 0 60000
+# nand write 100000 0 60000
+
+
+September 07 2006, Stefan Roese <sr@denx.de>
diff --git a/marvell/uboot/doc/README.ne2000 b/marvell/uboot/doc/README.ne2000
new file mode 100644
index 0000000..d5ae9a9
--- /dev/null
+++ b/marvell/uboot/doc/README.ne2000
@@ -0,0 +1,38 @@
+This driver supports NE2000 compatible cards (those based on DP8390,
+DP83902 and similar). It can be used with PCMCIA/CF cards provided
+that the CCR is correctly initialized.
+
+The code is based on sources from the Linux kernel (pcnet_cs.c,
+8390.h) and eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2
+wonderful world are GPL, so this is, of course, GPL.
+
+I developed and tested this driver on a custom PXA255 based system and
+with a billionton CF network card connected to the PCMCIA interface of
+the micro (have a look at README.PXA_CF for the support of this port).
+
+The options you have to specify in the config file are (with the
+value for my board as an example):
+
+#define CONFIG_DRIVER_NE2000
+
+- Enables the driver
+
+#define CONFIG_DRIVER_NE2000_BASE (0x20000000+0x300)
+
+- Address where the board is mapped
+
+#define CONFIG_DRIVER_NE2000_CCR (0x28000000+0x3f8)
+
+- Address of the CCR (card configuration register). It could be found
+by enabling DEBUG in cmd_pcmcia.c. If this is not defined nothing is
+done as far as PCMCIA support is concerned.
+
+#define CONFIG_DRIVER_NE2000_VAL (0x20)
+
+- The value to be written in the CCR. It selects among different I/O
+spaces that could be used by the card.
+
+
+Enjoy!
+
+Christian Pellegrin <chri@ascensit.com>
diff --git a/marvell/uboot/doc/README.nokia_rx51 b/marvell/uboot/doc/README.nokia_rx51
new file mode 100644
index 0000000..586ed7c
--- /dev/null
+++ b/marvell/uboot/doc/README.nokia_rx51
@@ -0,0 +1,104 @@
+Board: Nokia RX-51 aka N900
+
+This board definition results in a u-boot.bin which can be chainloaded
+from NOLO in qemu or on a real N900. It does very little hardware config
+because NOLO has already configured the board. Only needed is enabling
+internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
+
+NOLO is expecting a kernel image and will treat any image it finds in
+onenand as such. This u-boot is intended to be flashed to the N900 like
+a kernel. In order to transparently boot the original kernel, it will be
+appended to u-boot.bin at 0x40000. NOLO will load the entire image into
+(random) memory and execute u-boot, which saves hw revision, boot reason
+and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
+uImage or boot.scr from a fat, ext2/ext3 or ext4 filesystem in external
+SD card or internal eMMC memory. If this fails or keyboard is closed then
+the appended kernel image will be booted using some generated and some
+stored ATAGs (see boot order).
+
+There is support for hardware watchdog. Hardware watchdog is started by
+NOLO so u-boot must kick watchdog to prevent reboot device (but not very
+often, max every 2 seconds). There is also support for framebuffer display
+output with ANSI espace codes and the N900 HW keyboard input. USB tty works
+but is disabled because it prevents the current Maemo kernel from booting.
+
+When U-Boot is starting it enable IBE bit in Auxiliary Control Register,
+which is needed for Thumb-2 ISA support. It is workaround for errata 430973.
+
+Default boot order:
+
+ * 0. if keyboard is closed boot automatically attached kernel image
+ * 1. try boot from external SD card
+ * 2. try boot from internal eMMC memory
+ * 3. try boot from attached kernel image
+
+Boot from SD or eMMC in this order:
+
+ * 1.
+ * 1.1 find boot.scr on first fat partition
+ * 1.2 find uImage on first fat parition
+ * 1.3 same order for 2. - 4. fat partition
+ * 2. same as 1. but for ext2/3 partition
+ * 3. same as 1. but for ext4 partition
+
+
+Available additional commands/variables:
+
+ * run sercon - Use serial port for control
+ * run usbcon - Use usbtty for control
+ * run vgacon - Use framebuffer and HW keyboard for control (default)
+
+ * run sdboot - Boot from external SD card (see boot order)
+ * run emmcboot - Boot from internal eMMC memory (see boot order)
+ * run attachboot - Boot attached kernel image (attached to U-Boot binary)
+
+ * run scriptload - Load boot script ${mmcscriptfile}
+ * run scriptboot - Run loaded boot script
+ * run kernload - Load kernel image ${mmckernfile}
+ * run initrdload - Load initrd image ${mmcinitrdfile}
+ * run kernboot - Boot loaded kernel image
+ * run kerninitrdboot - Boot loaded kernel image with loaded initrd image
+
+ * run trymmcscriptboot - Try to load and boot script ${mmcscriptfile}
+ * run trymmckernboot - Try to load and boot kernel image ${mmckernfile}
+ * run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile}
+ with initrd image ${mmcinitrdfile}
+
+Additional variables for loading files from mmc:
+
+ * mmc ${mmcnum} (0 - external, 1 - internal)
+ * partition number ${mmcpart} (1 - 4)
+ * parition type ${mmctype} (fat, ext2)
+
+Additional varuables for booting kernel:
+
+ * setup_omap_atag - Add OMAP table into atags structure (needs maemo kernel)
+ * setup_console_atag - Enable serial console in OMAP table
+ * setup_boot_reason_atag - Change boot reason in OMAP table
+ * setup_boot_mode_atag - Change boot mode in OMAP table
+
+USB TTY:
+
+ Maemo kernel 2.6.28 will crash if u-boot enable usb tty. So USB TTY is disabled.
+ For enabling USB TTY just add this line to file include/configs/nokia_rx51.h
+
+ #define CONFIG_USB_TTY
+
+
+ONENAND support:
+
+ ONENAND support is disabled because not working yet and cause linux kernel to
+ crash or no access to mtd. For enabling ONENAND support add this line at begin
+ of file include/configs/nokia_rx51.h
+
+ #define ONENAND_SUPPORT
+
+
+UBIFS support:
+
+ UBIFS support is disabled, because U-Boot image is too big and cannot be
+ flashed with attached zImage to RX-51 kernel nand area. For enabling UBIFS
+ support first enable ONENAND support and then add this line at begin of file
+ include/configs/nokia_rx51.h
+
+ #define UBIFS_SUPPORT
diff --git a/marvell/uboot/doc/README.omap-reset-time b/marvell/uboot/doc/README.omap-reset-time
new file mode 100644
index 0000000..0c974ba
--- /dev/null
+++ b/marvell/uboot/doc/README.omap-reset-time
@@ -0,0 +1,20 @@
+README on how reset time on OMAPs should be calculated
+
+CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC:
+Most OMAPs' provide a way to specify the time for
+which the reset should be held low while the voltages
+and Oscillator outputs stabilize.
+
+This time is mostly board and PMIC dependent. Hence the
+boards are expected to specify a pre-computed time
+using the above option, (the details on how to compute
+the value are given below) without which a default time
+as specified by CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC
+is used.
+
+The value for CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC
+can be computed using a summation of the below 3 parameters
+-1- Time taken by the Osciallator to stop and restart
+-2- PMIC OTP time
+-3- Voltage ramp time, which can be derived using the
+PMIC slew rate and value of voltage ramp needed.
diff --git a/marvell/uboot/doc/README.omap-ulpi-viewport b/marvell/uboot/doc/README.omap-ulpi-viewport
new file mode 100644
index 0000000..a5240b9
--- /dev/null
+++ b/marvell/uboot/doc/README.omap-ulpi-viewport
@@ -0,0 +1,27 @@
+Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c"
+
+Contains the ulpi read write api's to perform
+any ulpi phy port access on omap platform.
+
+On omap ehci reg map contains INSNREG05_ULPI
+register which offers the ulpi phy access so
+any ulpi phy commands should be passsed using this
+register.
+
+omap-ulpi-viewport.c is a low level function
+implementation of "drivers/usb/ulpi/ulpi.c"
+
+To enable and use omap-ulpi-viewport.c
+we require CONFIG_USB_ULPI_VIEWPORT_OMAP and
+CONFIG_USB_ULPI be enabled in config file.
+
+Any ulpi ops request can be done with ulpi.c
+and soc specific binding and usage is done with
+omap-ulpi-viewport implementation.
+
+Ex: scenario:
+omap-ehci driver code requests for ulpi phy reset if
+ehci is used in phy mode, which will call ulpi phy reset
+the ulpi phy reset does ulpi_read/write from viewport
+implementation which will do ulpi reset using the
+INSNREG05_ULPI register.
diff --git a/marvell/uboot/doc/README.omap3 b/marvell/uboot/doc/README.omap3
new file mode 100644
index 0000000..a62c357
--- /dev/null
+++ b/marvell/uboot/doc/README.omap3
@@ -0,0 +1,220 @@
+
+Summary
+=======
+
+This README is about U-Boot support for TI's ARM Cortex-A8 based OMAP3 [1]
+family of SoCs. TI's OMAP3 SoC family contains an ARM Cortex-A8. Additionally,
+some family members contain a TMS320C64x+ DSP and/or an Imagination SGX 2D/3D
+graphics processor and various other standard peripherals.
+
+Currently the following boards are supported:
+
+* OMAP3530 BeagleBoard [2]
+
+* Gumstix Overo [3]
+
+* TI EVM [4]
+
+* OpenPandora Ltd. Pandora [5]
+
+* TI/Logic PD Zoom MDK [6]
+
+* TI/Logic PD Zoom 2 [7]
+
+* CompuLab Ltd. CM-T35 [8]
+
+Toolchain
+=========
+
+While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
+with -march=armv5 to allow more compilers to work. For U-Boot code this has
+no performance impact.
+
+Build
+=====
+
+* BeagleBoard:
+
+make omap3_beagle_config
+make
+
+* Gumstix Overo:
+
+make omap3_overo_config
+make
+
+* TI EVM:
+
+make omap3_evm_config
+make
+
+* Pandora:
+
+make omap3_pandora_config
+make
+
+* Zoom MDK:
+
+make omap3_zoom1_config
+make
+
+* Zoom 2:
+
+make omap3_zoom2_config
+make
+
+* CM-T35:
+
+make cm_t35_config
+make
+
+* BlueLYNX-X:
+
+make omap3_mvblx_config
+make
+
+Custom commands
+===============
+
+To make U-Boot for OMAP3 support NAND device SW or HW ECC calculation, U-Boot
+for OMAP3 supports custom user command
+
+nandecc hw/sw
+
+To be compatible with NAND drivers using SW ECC (e.g. kernel code)
+
+nandecc sw
+
+enables SW ECC calculation. HW ECC enabled with
+
+nandecc hw
+
+is typically used to write 2nd stage bootloader (known as 'x-loader') which is
+executed by OMAP3's boot rom and therefore has to be written with HW ECC.
+
+For all other commands see
+
+help
+
+Interfaces
+==========
+
+gpio
+----
+
+To set a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_output(N, 0);
+ gpio_set_value(N, 1);
+ }
+
+To clear a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_output(N, 0);
+ gpio_set_value(N, 0);
+ }
+
+To read a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_input(N);
+ val = gpio_get_value(N);
+ gpio_free(N);
+ }
+ if (val)
+ printf("GPIO N is set\n");
+ else
+ printf("GPIO N is clear\n");
+
+dma
+---
+void omap3_dma_init(void)
+ Init the DMA module
+int omap3_dma_get_conf_chan(uint32_t chan, struct dma4_chan *config);
+ Read config of the channel
+int omap3_dma_conf_chan(uint32_t chan, struct dma4_chan *config);
+ Write config to the channel
+int omap3_dma_conf_transfer(uint32_t chan, uint32_t *src, uint32_t *dst,
+ uint32_t sze)
+ Config source, destination and size of a transfer
+int omap3_dma_wait_for_transfer(uint32_t chan)
+ Wait for a transfer to end - this hast to be called before a channel
+ or the data the channel transferd are used.
+int omap3_dma_get_revision(uint32_t *minor, uint32_t *major)
+ Read silicon Revision of the DMA module
+
+NAND
+====
+
+There are some OMAP3 devices out there with NAND attached. Due to the fact that
+OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page
+(place where SPL lives) we require this setup for u-boot at least when reading
+the second progam within SPL. A lot of newer NAND chips however require more
+than 1-bit ECC for the pages, some can live with 1-bit for the first page. To
+handle this we can switch to another ECC algorithm after reading the payload
+within SPL.
+
+BCH8
+----
+
+To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on
+OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH
+and set CONFIG_NAND_OMAP_ECCSCHEME=5 (refer README.nand) for selecting BCH8_SW.
+The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8
+implementation for OMAP3 works for you so the u-boot version should also.
+When you require the SPL to read with BCH8 there are two more configs to
+change:
+
+ * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in
+ GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in
+ arch/arm/include/asm/arch-omap3/omap_gpmc.h)
+ * CONFIG_SYS_NAND_ECCSIZE must be 512
+ * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup
+
+Acknowledgements
+================
+
+OMAP3 U-Boot is based on U-Boot tar ball [9] for BeagleBoard and EVM done by
+several TI employees.
+
+Links
+=====
+
+[1] OMAP3:
+
+http://www.ti.com/omap3 (high volume) and
+http://www.ti.com/omap35x (broad market)
+
+[2] OMAP3530 BeagleBoard:
+
+http://beagleboard.org/
+
+[3] Gumstix Overo:
+
+http://www.gumstix.net/Overo/
+
+[4] TI EVM:
+
+http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html
+
+[5] OpenPandora Ltd. Pandora:
+
+http://openpandora.org/
+
+[6] TI/Logic PD Zoom MDK:
+
+http://www.logicpd.com/products/devkit/ti/zoom_mobile_development_kit
+
+[7] TI/Logic PD Zoom 2
+
+http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
+
+[8] CompuLab Ltd. CM-T35:
+
+http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm
+
+[9] TI OMAP3 U-Boot:
+
+http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
diff --git a/marvell/uboot/doc/README.pblimage b/marvell/uboot/doc/README.pblimage
new file mode 100644
index 0000000..7fdd26b
--- /dev/null
+++ b/marvell/uboot/doc/README.pblimage
@@ -0,0 +1,111 @@
+------------------------------------------------------------------
+Freescale PBL(pre-boot loader) Boot Image generation using mkimage
+------------------------------------------------------------------
+
+The CoreNet SoC's can boot directly from eSPI FLASH, SD/MMC and
+NAND, etc. These SoCs use PBL to load RCW and/or pre-initialization
+instructions. For more details refer section 5 Pre-boot loader
+specifications of reference manual P3041RM/P4080RM/P5020RM at link:
+http://www.freescale.com/webapp/search/Serp.jsp?Reference+Manuals
+
+Building PBL Boot Image and boot steps
+--------------------------------------
+
+1. Building PBL Boot Image.
+ The default Image is u-boot.pbl.
+
+ For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
+ To build the eSPI boot image:
+ make <board_name>_SPIFLASH
+
+ For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
+ To build the SD boot image:
+ make <board_name>_SDCARD
+
+ For Nand boot(available on P2041/P3041/P5020/P5040):
+ To build the NAND boot image:
+ make <board_name>_NAND
+
+
+2. pblimage support available with mkimage utility will generate Freescale PBL
+boot image that can be flashed on the board eSPI flash, SD/MMC and NAND.
+Following steps describe it in detail.
+
+ 1). Boot from eSPI flash
+ Write u-boot.pbl to eSPI flash from offset 0x0.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>sf probe 0
+ =>sf erase 0 100000
+ =>sf write 100000 0 $filesize
+ Change SW1[1:5] = off off on off on.
+
+ 2). Boot from SD/MMC
+ Write u-boot.pbl to SD/MMC from offset 0x1000.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>mmcinfo
+ =>mmc write 100000 8 441
+ Change SW1[1:5] = off off on on off.
+
+ 3). Boot from Nand
+ Write u-boot.pbl to Nand from offset 0x0.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>nand info
+ =>nand erase 0 100000
+ =>nand write 100000 0 $filesize
+ Change SW1[1:5] = off on off off on
+ Change SW7[1:4] = on off off on
+
+Board specific configuration file specifications:
+------------------------------------------------
+1. Configuration files rcw.cfg and pbi.cfg must present in the
+board/freescale/corenet_ds/, rcw.cfg is for RCW, pbi.cfg is for
+PBI instructions. File name must not be changed since they are used
+in Makefile.
+2. These files can have empty lines and lines starting with "#" as first
+character to put comments
+
+Typical example of rcw.cfg file:
+-----------------------------------
+
+#PBL preamble and RCW header
+aa55aa55 010e0100
+#64 bytes RCW data
+4c580000 00000000 18185218 0000cccc
+40464000 3c3c2000 58000000 61000000
+00000000 00000000 00000000 008b6000
+00000000 00000000 00000000 00000000
+
+Typical example of pbi.cfg file:
+-----------------------------------
+
+#PBI commands
+#Initialize CPC1
+09010000 00200400
+09138000 00000000
+091380c0 00000100
+09010100 00000000
+09010104 fff0000b
+09010f00 08000000
+09010000 80000000
+#Configure LAW for CPC1
+09000d00 00000000
+09000d04 fff00000
+09000d08 81000013
+09000010 00000000
+09000014 ff000000
+09000018 81000000
+#Initialize eSPI controller
+09110000 80000403
+09110020 2d170008
+09110024 00100008
+09110028 00100008
+0911002c 00100008
+#Flush PBL data
+09138000 00000000
+091380c0 00000000
+
+------------------------------------------------
+Author: Shaohui Xie<Shaohui.Xie@freescale.com>
diff --git a/marvell/uboot/doc/README.plan9 b/marvell/uboot/doc/README.plan9
new file mode 100644
index 0000000..2d3d0e0
--- /dev/null
+++ b/marvell/uboot/doc/README.plan9
@@ -0,0 +1,18 @@
+Plan 9 from Bell Labs kernel images require additional setup to pass
+configuration information to the kernel. An environment variable named
+confaddr must be defined with the same value as CONFADDR (see mem.h).
+Use of this facility is optional, but should be preferable to manual
+configuration.
+
+When booting an image, arguments supplied to the bootm command will be
+copied to CONFADDR. If no arguments are specified, the contents of the
+bootargs environment variable will be copied.
+
+If no command line arguments or bootargs are defined, CONFADDR is left
+uninitialized to permit manual configuration. For example, PC-style
+configuration could be simulated by issuing a fatload in bootcmd:
+
+ # setenv bootcmd fatload mmc 0 $confaddr plan9.ini; ...; bootm
+
+Steven Stallion
+June 2013
diff --git a/marvell/uboot/doc/README.ppc440 b/marvell/uboot/doc/README.ppc440
new file mode 100644
index 0000000..dd8ccaa
--- /dev/null
+++ b/marvell/uboot/doc/README.ppc440
@@ -0,0 +1,197 @@
+ PowerPC 440
+
+ Last Update: September 11, 2002
+=======================================================================
+
+
+OVERVIEW
+============
+
+Support for the ppc440 is contained in the cpu/ppc44x directory
+and enabled via the CONFIG_440 flag. It is largely based on the
+405gp code. A sample board support implementation is contained
+in the board/ebony directory.
+
+All testing was performed using the AMCC Ebony board using both
+Rev B and Rev C silicon. However, since the Rev B. silicon has
+extensive errata, support for Rev B. is minimal (it boots, and
+features such as i2c, pci, tftpboot, etc. seem to work ok).
+The expectation is that all new board designs will be using
+Rev C or later parts -- if not, you may be in for a rough ride ;-)
+
+The ppc440 port does a fair job of keeping "board-specific" code
+out of the "cpu-specific" source. The goal of course was to
+provide mechanisms for each board to customize without having
+to clutter the cpu-specific source with a lot of ifdefs. Most
+of these mechanisms are described in the following sections.
+
+
+MEMORY MANAGEMENT
+=================
+
+The ppc440 doesn't run in "real mode". The MMU must be active
+at all times. Additionally, the 440 implements a 36-bit physical
+memory space that gets mapped into the PowerPC 32-bit virtual
+address space. So things like memory-mapped peripherals, etc must
+all be mapped in. Once this is done, the 32-bit virtual address
+space is then viewed as though it were physical memory.
+
+However, this means that memory, peripherals, etc can be configured
+to appear (mostly) anywhere in the virtual address space. Each board
+must define its own mappings using the tlbtab (see board/ebony/init.S).
+The actual TLB setup is performed by the cpu-specific code.
+
+Although each board is free to define its own mappings, there are
+several definitions to be aware of. These definitions may be used in
+the cpu-specific code (vs. board-specific code), so you should
+at least review these before deciding to make any changes ... it
+will probably save you some headaches ;-)
+
+CONFIG_SYS_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)
+
+CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped.
+
+CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
+ This mapping provides access to PCI-bus memory.
+
+CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
+ peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).
+
+CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is
+ mapped. The internal SRAM is equivalent to 405gp OCM and is used
+ for the initial stack.
+
+CONFIG_SYS_PCI_BASE - The virtual address where the 440 PCI-x bridge config
+ registers are mapped.
+
+CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address
+ defined by CONFIG_SYS_PCI_MEMBASE.
+
+
+UART / SERIAL
+=================
+
+The UART port works fine when an external serial clock is provided
+(like the one on the Ebony board) and when using internal clocking.
+This is controlled with the CONFIG_SYS_EXT_SERIAL_CLOCK flag. When using
+internal clocking, the "ideal baud rate" settings in the 440GP
+user manual are automatically calculated.
+
+
+I2C
+=================
+
+The i2c utilities have been tested on both Rev B. and Rev C. and
+look good. The 'i2c probe' command implementation has been updated to
+allow for 'skipped' addresses. Some i2c slaves are write only and
+cause problems when a probe (read) is performed (for example the
+CDCV850 clock controller at address 0x69 on the ebony board).
+
+To prevent probing certain addresses you can define the
+CONFIG_SYS_I2C_NOPROBES macro in your board-specific header file. When
+defined, all specified addresses are skipped during a probe.
+The addresses that are skipped will be displayed in the output
+of the 'i2c probe' command.
+
+For example, to prevent probing address 0x69, define the macro as
+follows:
+
+#define CONFIG_SYS_I2C_NOPROBES {0x69}
+
+Similarly, to prevent probing addresses 0x69 and 0x70, define the
+macro a:
+
+#define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70}
+
+
+DDR SDRAM CONTROLLER
+====================
+
+SDRAM controller intialization using Serial Presence Detect (SPD) is
+now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
+The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.
+
+NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
+processors. Traditionally, it defined a single address. For the 440 it
+defines an array of addresses to support multiple banks. Address order
+is significant: the addresses are used in order to program the BankN
+registers. For example, two banks with i2c addresses of 0x53 (bank 0)
+and 0x52 (bank 1) would be defined as follows:
+
+#define SPD_EEPROM_ADDRESS {0x53,0x52}
+
+
+PCI-X BRIDGE
+====================
+
+PCI is an area that requires lots of flexibility since every board has
+its own set of constraints and configuration. This section describes the
+440 implementation.
+
+CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
+is aborted and an indication is printed. This is NOT considered an
+error -- only an indication that PCI shouldn't be initialized. This
+gives you a chance to edit the i2c bootstrap eeproms using the i2c
+utilities once you get to the U-Boot command prompt. NOTE: the default
+440 bootstrap options (not using i2c eeprom) negates this bit.
+
+The cpu-specific code sets up a default pci_controller structure
+that maps in a single PCI I/O space and PCI memory space. The I/O
+space begins at PCI I/O address 0 and the PCI memory space is
+256 MB starting at PCI address CONFIG_SYS_PCI_TARGBASE. After the
+pci_controller structure is initialized, the cpu-specific code will
+call the routine pci_pre_init(). This routine is implemented by
+board-specific code & is where the board can over-ride/extend the
+default pci_controller structure settings and exspecially provide
+a routine to map the PCI interrupts and do other pre-initialization
+tasks. If pci_pre_init() returns a value of zero, PCI initialization
+is aborted; otherwise the controller structure is registered and
+initialization continues.
+
+The default 440GP PCI target configuration is minimal -- it assumes that
+the strapping registers are set as necessary. Since the strapping bits
+provide very limited flexibility, you may want to customize the boards
+target configuration. If CONFIG_SYS_PCI_TARGET_INIT is defined, the cpu-specific
+code will call the routine pci_target_init() which you must implement
+in your board-specific code.
+
+Target initialization is completed by the cpu-specific code by
+initializing the subsystem id and subsystem vendor id, and then ensuring
+that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.
+
+The default PCI master initialization maps in 256 MB of pci memory
+starting at PCI address CONFIG_SYS_PCI_MEMBASE. To customize this, define
+PCI_MASTER_INIT. This will call the routine pci_master_init() in your
+board-specific code rather than performing the default master
+initialization.
+
+The decision to perform PCI host configuration must often be determined
+at run time. The ppc440 port differs from most other implementations in
+that it requires the board to determine its host configuration at run
+time rather than by using compile-time flags. This shouldn't create a
+large impact on the board-specific code since the board only needs to
+implement a single routine that returns a zero or non-zero value:
+is_pci_host().
+
+Justification for this becomes clear when considering systems running
+in a cPCI environment:
+
+1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
+part of the PCI-to-PCI bridge). Even though the arbiter is external (the
+arbiter strapping is negated), the CPU may still be required to perform
+local PCI bus configuration.
+
+2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
+Depending on the configuration of the carrier boar, the PPMC board must
+determine if it should configure the PCI bus at run-time. And in most
+cases, access to the MONARCH# signal is board-specific (e.g. via
+board-specific FPGA registers, etc).
+
+In any event, the is_pci_host() routine gives each board the opportunity
+to decide at run-time. If your board is always configured a certain way,
+then just hardcode a return of 1 or 0 as appropriate.
+
+
+Regards,
+--Scott
+<smcnutt@artesyncp.com>
diff --git a/marvell/uboot/doc/README.pxe b/marvell/uboot/doc/README.pxe
new file mode 100644
index 0000000..f67605c
--- /dev/null
+++ b/marvell/uboot/doc/README.pxe
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2010-2011 Calxeda, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+The 'pxe' commands provide a near subset of the functionality provided by
+the PXELINUX boot loader. This allows U-boot based systems to be controlled
+remotely using the same PXE based techniques that many non U-boot based servers
+use.
+
+Commands
+========
+
+pxe get
+-------
+ syntax: pxe get
+
+ follows PXELINUX's rules for retrieving configuration files from a tftp
+ server, and supports a subset of PXELINUX's config file syntax.
+
+ Environment
+ -----------
+ 'pxe get' requires two environment variables to be set:
+
+ pxefile_addr_r - should be set to a location in RAM large enough to hold
+ pxe files while they're being processed. Up to 16 config files may be
+ held in memory at once. The exact number and size of the files varies with
+ how the system is being used. A typical config file is a few hundred bytes
+ long.
+
+ bootfile,serverip - these two are typically set in the DHCP response
+ handler, and correspond to fields in the DHCP response.
+
+ 'pxe get' optionally supports these two environment variables being set:
+
+ ethaddr - this is the standard MAC address for the ethernet adapter in use.
+ 'pxe get' uses it to look for a configuration file specific to a system's
+ MAC address.
+
+ pxeuuid - this is a UUID in standard form using lower case hexadecimal
+ digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses
+ it to look for a configuration file based on the system's UUID.
+
+ File Paths
+ ----------
+ 'pxe get' repeatedly tries to download config files until it either
+ successfully downloads one or runs out of paths to try. The order and
+ contents of paths it tries mirrors exactly that of PXELINUX - you can
+ read in more detail about it at:
+
+ http://syslinux.zytor.com/wiki/index.php/Doc/pxelinux
+
+pxe boot
+--------
+ syntax: pxe boot [pxefile_addr_r]
+
+ Interprets a pxe file stored in memory.
+
+ pxefile_addr_r is an optional argument giving the location of the pxe file.
+ The file must be terminated with a NUL byte.
+
+ Environment
+ -----------
+ There are some environment variables that may need to be set, depending
+ on conditions.
+
+ pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied,
+ an environment variable named pxefile_addr_r must be supplied. This is
+ typically the same value as is used for the 'pxe get' command.
+
+ bootfile - typically set in the DHCP response handler based on the
+ same field in the DHCP respone, this path is used to generate the base
+ directory that all other paths to files retrieved by 'pxe boot' will use.
+ If no bootfile is specified, paths used in pxe files will be used as is.
+
+ serverip - typically set in the DHCP response handler, this is the IP
+ address of the tftp server from which other files will be retrieved.
+
+ kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will
+ store the kernel and initrd it retrieves from tftp. These locations will
+ be passed to the bootm command to boot the kernel. These environment
+ variables are required to be set.
+
+ fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it
+ retrieves from tftp. The retrieval is possible if 'fdt' label is defined in
+ pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
+ will be passed to bootm command to boot the kernel.
+
+ fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm
+ command if it is set and 'fdt_addr_r' is not passed to bootm command.
+
+pxe file format
+===============
+The pxe file format is nearly a subset of the PXELINUX file format; see
+http://syslinux.zytor.com/wiki/index.php/PXELINUX. It's composed of one line
+commands - global commands, and commands specific to labels. Lines begining
+with # are treated as comments. White space between and at the beginning of
+lines is ignored.
+
+The size of pxe files and the number of labels is only limited by the amount
+of RAM available to U-boot. Memory for labels is dynamically allocated as
+they're parsed, and memory for pxe files is statically allocated, and its
+location is given by the pxefile_addr_r environment variable. The pxe code is
+not aware of the size of the pxefile memory and will outgrow it if pxe files
+are too large.
+
+Supported global commands
+-------------------------
+Unrecognized commands are ignored.
+
+default <label> - the label named here is treated as the default and is
+ the first label 'pxe boot' attempts to boot.
+
+menu title <string> - sets a title for the menu of labels being displayed.
+
+menu include <path> - use tftp to retrieve the pxe file at <path>, which
+ is then immediately parsed as if the start of its
+ contents were the next line in the current file. nesting
+ of include up to 16 files deep is supported.
+
+prompt <flag> - if 1, always prompt the user to enter a label to boot
+ from. if 0, only prompt the user if timeout expires.
+
+timeout <num> - wait for user input for <num>/10 seconds before
+ auto-booting a node.
+
+label <name> - begin a label definition. labels continue until
+ a command not recognized as a label command is seen,
+ or EOF is reached.
+
+Supported label commands
+------------------------
+labels end when a command not recognized as a label command is reached, or EOF.
+
+menu default - set this label as the default label to boot; this is
+ the same behavior as the global default command but
+ specified in a different way
+
+kernel <path> - if this label is chosen, use tftp to retrieve the kernel
+ at <path>. it will be stored at the address indicated in
+ the kernel_addr_r environment variable, and that address
+ will be passed to bootm to boot this kernel.
+
+append <string> - use <string> as the kernel command line when booting this
+ label.
+
+initrd <path> - if this label is chosen, use tftp to retrieve the initrd
+ at <path>. it will be stored at the address indicated in
+ the initrd_addr_r environment variable, and that address
+ will be passed to bootm.
+
+fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob
+ at <path>. it will be stored at the address indicated in
+ the fdt_addr_r environment variable, and that address will
+ be passed to bootm.
+
+localboot <flag> - Run the command defined by "localcmd" in the environment.
+ <flag> is ignored and is only here to match the syntax of
+ PXELINUX config files.
+
+Example
+-------
+Here's a couple of example files to show how this works.
+
+------------/tftpboot/pxelinux.cfg/menus/linux.list----------
+menu title Linux selections
+
+# This is the default label
+label install
+ menu label Default Install Image
+ kernel kernels/install.bin
+ append console=ttyAMA0,38400 debug earlyprintk
+ initrd initrds/uzInitrdDebInstall
+
+# Just another label
+label linux-2.6.38
+ kernel kernels/linux-2.6.38.bin
+ append root=/dev/sdb1
+
+# The locally installed kernel
+label local
+ menu label Locally installed kernel
+ append root=/dev/sdb1
+ localboot 1
+-------------------------------------------------------------
+
+------------/tftpboot/pxelinux.cfg/default-------------------
+menu include pxelinux.cfg/menus/base.menu
+timeout 500
+
+default linux-2.6.38
+-------------------------------------------------------------
+
+When a pxe client retrieves and boots the default pxe file,
+'pxe boot' will wait for user input for 5 seconds before booting
+the linux-2.6.38 label, which will cause /tftpboot/kernels/linux-2.6.38.bin
+to be downloaded, and boot with the command line "root=/dev/sdb1"
+
+Differences with PXELINUX
+=========================
+The biggest difference between U-boot's pxe and PXELINUX is that since
+U-boot's pxe support is written entirely in C, it can run on any platform
+with network support in U-boot. Here are some other differences between
+PXELINUX and U-boot's pxe support.
+
+- U-boot's pxe does not support the PXELINUX DHCP option codes specified
+ in RFC 5071, but could be extended to do so.
+
+- when U-boot's pxe fails to boot, it will return control to U-boot,
+ allowing another command to run, other U-boot command, instead of resetting
+ the machine like PXELINUX.
+
+- U-boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
+ only uses U-boot.
+
+- U-boot's pxe doesn't provide the full menu implementation that PXELINUX
+ does, only a simple text based menu using the commands described in
+ this README. With PXELINUX, it's possible to have a graphical boot
+ menu, submenus, passwords, etc. U-boot's pxe could be extended to support
+ a more robust menuing system like that of PXELINUX's.
+
+- U-boot's pxe expects U-boot uimg's as kernels. Anything that would work
+ with the 'bootm' command in U-boot could work with the 'pxe boot' command.
+
+- U-boot's pxe only recognizes a single file on the initrd command line. It
+ could be extended to support multiple.
+
+- in U-boot's pxe, the localboot command doesn't necessarily cause a local
+ disk boot - it will do whatever is defined in the 'localcmd' env
+ variable. And since it doesn't support a full UNDI/PXE stack, the
+ type field is ignored.
+
+- the interactive prompt in U-boot's pxe only allows you to choose a label
+ from the menu. If you want to boot something not listed, you can ctrl+c
+ out of 'pxe boot' and use existing U-boot commands to accomplish it.
diff --git a/marvell/uboot/doc/README.qemu-mips b/marvell/uboot/doc/README.qemu-mips
new file mode 100644
index 0000000..a192752
--- /dev/null
+++ b/marvell/uboot/doc/README.qemu-mips
@@ -0,0 +1,195 @@
+By Vlad Lungu vlad.lungu@windriver.com 2007-Oct-01
+----------------------------------------
+Qemu is a full system emulator. See
+
+http://www.nongnu.org/qemu/
+
+Limitations & comments
+----------------------
+Supports the "-M mips" configuration of qemu: serial,NE2000,IDE.
+Supports little and big endian as well as 32 bit and 64 bit.
+Derived from au1x00 with a lot of things cut out.
+
+Supports emulated flash (patch Jean-Christophe PLAGNIOL-VILLARD) with
+recent qemu versions. When using emulated flash, launch with
+-pflash <filename> and erase mips_bios.bin.
+
+
+Notes for the Qemu MIPS port
+----------------------------
+
+I) Example usage:
+
+Using u-boot.bin as ROM (replaces Qemu monitor):
+
+32 bit, big endian:
+# make qemu_mips
+# qemu-system-mips -M mips -bios u-boot.bin -nographic
+
+32 bit, little endian:
+# make qemu_mipsel
+# qemu-system-mipsel -M mips -bios u-boot.bin -nographic
+
+64 bit, big endian:
+# make qemu_mips64
+# qemu-system-mips64 -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic
+
+64 bit, little endian:
+# make qemu_mips64el
+# qemu-system-mips64el -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic
+
+or using u-boot.bin from emulated flash:
+
+if you use a qemu version after commit 4224
+
+create image:
+# dd of=flash bs=1k count=4k if=/dev/zero
+# dd of=flash bs=1k conv=notrunc if=u-boot.bin
+start it (see above):
+# qemu-system-mips[64][el] [-cpu MIPS64R2-generic] -M mips -pflash flash -nographic
+
+2) Download kernel + initrd
+
+On ftp://ftp.denx.de/pub/contrib/Jean-Christophe_Plagniol-Villard/qemu_mips/
+you can downland
+
+#config to build the kernel
+qemu_mips_defconfig
+#patch to fix mips interrupt init on 2.6.24.y kernel
+qemu_mips_kernel.patch
+initrd.gz
+vmlinux
+vmlinux.bin
+System.map
+
+4) Generate uImage
+
+# tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x80010000 -e 0x80245650 -n "Linux 2.6.24.y" -d vmlinux.bin.gz uImage
+
+5) Copy uImage to Flash
+# dd if=uImage bs=1k conv=notrunc seek=224 of=flash
+
+6) Generate Ide Disk
+
+# dd of=ide bs=1k cout=100k if=/dev/zero
+
+# sfdisk -C 261 -d ide
+# partition table of ide
+unit: sectors
+
+ ide1 : start= 63, size= 32067, Id=83
+ ide2 : start= 32130, size= 32130, Id=83
+ ide3 : start= 64260, size= 4128705, Id=83
+ ide4 : start= 0, size= 0, Id= 0
+
+7) Copy to ide
+
+# dd if=uImage bs=512 conv=notrunc seek=63 of=ide
+
+8) Generate ext2 on part 2 on Copy uImage and initrd.gz
+
+# Attached as loop device ide offset = 32130 * 512
+# losetup -o 16450560 -f ide
+# Format as ext2 ( arg2 : nb blocks)
+# mke2fs /dev/loop0 16065
+# losetup -d /dev/loop0
+# Mount and copy uImage and initrd.gz to it
+# mount -o loop,offset=16450560 -t ext2 ide /mnt
+# mkdir /mnt/boot
+# cp {initrd.gz,uImage} /mnt/boot/
+# Umount it
+# umount /mnt
+
+9) Set Environment
+
+setenv rd_start 0x80800000
+setenv rd_size 2663940
+setenv kernel BFC38000
+setenv oad_addr 80500000
+setenv load_addr2 80F00000
+setenv kernel_flash BFC38000
+setenv load_addr_hello 80200000
+setenv bootargs 'root=/dev/ram0 init=/bin/sh'
+setenv load_rd_ext2 'ide res; ext2load ide 0:2 ${rd_start} /boot/initrd.gz'
+setenv load_rd_tftp 'tftp ${rd_start} /initrd.gz'
+setenv load_kernel_hda 'ide res; diskboot ${load_addr} 0:2'
+setenv load_kernel_ext2 'ide res; ext2load ide 0:2 ${load_addr} /boot/uImage'
+setenv load_kernel_tftp 'tftp ${load_addr} /qemu_mips/uImage'
+setenv boot_ext2_ext2 'run load_rd_ext2; run load_kernel_ext2; run addmisc; bootm ${load_addr}'
+setenv boot_ext2_flash 'run load_rd_ext2; run addmisc; bootm ${kernel_flash}'
+setenv boot_ext2_hda 'run load_rd_ext2; run load_kernel_hda; run addmisc; bootm ${load_addr}'
+setenv boot_ext2_tftp 'run load_rd_ext2; run load_kernel_tftp; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_hda 'run load_rd_tftp; run load_kernel_hda; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_ext2 'run load_rd_tftp; run load_kernel_ext2; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_flash 'run load_rd_tftp; run addmisc; bootm ${kernel_flash}'
+setenv boot_tftp_tftp 'run load_rd_tftp; run load_kernel_tftp; run addmisc; bootm ${load_addr}'
+setenv load_hello_tftp 'tftp ${load_addr_hello} /examples/hello_world.bin'
+setenv go_tftp 'run load_hello_tftp; go ${load_addr_hello}'
+setenv addmisc 'setenv bootargs ${bootargs} console=ttyS0,${baudrate} rd_start=${rd_start} rd_size=${rd_size} ethaddr=${ethaddr}'
+setenv bootcmd 'run boot_tftp_flash'
+
+10) Now you can boot from flash, ide, ide+ext2 and tfp
+
+# qemu-system-mips -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide
+
+II) How to debug U-Boot
+
+In order to debug U-Boot you need to start qemu with gdb server support (-s)
+and waiting the connection to start the CPU (-S)
+
+# qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide
+
+in an other console you start gdb
+
+1) Debugging of U-Boot Before Relocation
+
+Before relocation, the addresses in the ELF file can be used without any problems
+by connecting to the gdb server localhost:1234
+
+# mipsel-unknown-linux-gnu-gdb u-boot
+GNU gdb 6.6
+Copyright (C) 2006 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB. Type "show warranty" for details.
+This GDB was configured as "--host=i486-linux-gnu --target=mipsel-unknown-linux-gnu"...
+(gdb) target remote localhost:1234
+Remote debugging using localhost:1234
+_start () at start.S:64
+64 RVECENT(reset,0) /* U-boot entry point */
+Current language: auto; currently asm
+(gdb) b board.c:289
+Breakpoint 1 at 0xbfc00cc8: file board.c, line 289.
+(gdb) c
+Continuing.
+
+Breakpoint 1, board_init_f (bootflag=<value optimized out>) at board.c:290
+290 relocate_code (addr_sp, id, addr);
+Current language: auto; currently c
+(gdb) p/x addr
+$1 = 0x87fa0000
+
+2) Debugging of U-Boot After Relocation
+
+For debugging U-Boot after relocation we need to know the address to which
+U-Boot relocates itself to 0x87fa0000 by default.
+And replace the symbol table to this offset.
+
+(gdb) symbol-file
+Discard symbol table from `/private/u-boot-arm/u-boot'? (y or n) y
+Error in re-setting breakpoint 1:
+No symbol table is loaded. Use the "file" command.
+No symbol file now.
+(gdb) add-symbol-file u-boot 0x87fa0000
+add symbol table from file "u-boot" at
+ .text_addr = 0x87fa0000
+(y or n) y
+Reading symbols from /private/u-boot-arm/u-boot...done.
+Breakpoint 1 at 0x87fa0cc8: file board.c, line 289.
+(gdb) c
+Continuing.
+
+Program received signal SIGINT, Interrupt.
+0xffffffff87fa0de4 in udelay (usec=<value optimized out>) at time.c:78
+78 while ((tmo - read_c0_count()) < 0x7fffffff)
diff --git a/marvell/uboot/doc/README.ramboot-ppc85xx b/marvell/uboot/doc/README.ramboot-ppc85xx
new file mode 100644
index 0000000..5cc546a
--- /dev/null
+++ b/marvell/uboot/doc/README.ramboot-ppc85xx
@@ -0,0 +1,102 @@
+ RAMBOOT for MPC85xx Platforms
+ ==============================
+
+RAMBOOT literally means boot from DDR. But since DDR is volatile memory some
+pre-mechanism is required to load the DDR with the bootloader binary.
+- In case of SD and SPI boot this is done by BootROM code inside the chip
+ itself.
+- In case of NAND boot FCM supports loading initial 4K code from NAND flash
+ which can initialize the DDR and get the complete bootloader copied to DDR.
+
+In addition to the above there could be some more methods to initialize the DDR
+and load it manually.
+Two of them are described below.There is also an explanation as to where these
+methods could be handy.
+1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then
+ execute the bootloader from DDR.
+ This may be handy in the following cases:
+ - In very early stage of platform bringup where other boot options are not
+ functional because of various reasons.
+ - In case the support to program the flashes on the board is not available.
+
+2. Load the RAM based bootloader onto DDR using already existing bootloader on
+ the board.And then execute the bootloader from DDR.
+ Some usecases where this may be used:
+ - While developing some new feature of u-boot, for example USB driver or
+ SPI driver.
+ Suppose the board already has a working bootloader on it. And you would
+ prefer to keep it intact, at the same time want to test your bootloader.
+ In this case you can get your test bootloader binary into DDR via tftp
+ for example. Then execute the test bootloader.
+ - Suppose a platform already has a propreitery bootloader which does not
+ support for example AMP boot. In this case also RAM boot loader can be
+ utilized.
+
+ So basically when the original bootloader is required to be kept intact
+ RAM based bootloader can offer an updated bootloader on the system.
+
+Both the above Bootloaders are slight variants of SDcard or SPI Flash
+bootloader or for that matter even NAND bootloader.
+All of them define CONFIG_SYS_RAMBOOT.
+The main difference among all of them is the way the pre-environment is getting
+configured and who is doing that.
+- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself.
+- In case of NAND boot SPL/TPL code does it with some support from Si itself.
+- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader.
+
+How to use them:
+1. Using JTAG
+ Boot up in core hold off mode or stop the core after reset using JTAG
+ interface.
+ Preconfigure DDR/L2SRAM through JTAG interface.
+ - setup DDR controller registers.
+ - setup DDR LAWs
+ - setup DDR TLB
+ Load the RAM based boot loader to the proper location in DDR/L2SRAM.
+ set up IAR (Instruction counter properly)
+ Enable the core to execute.
+
+2. Using already existing bootloader.
+ get the rambased boot loader binary into DDR/L2SRAM via tftp.
+ execute the RAM based bootloader.
+ => tftp 11000000 u-boot-ram.bin
+ => go 1107f000
+
+Please note that L2SRAM can also be used instead of DDR if the SOC has
+sufficient size of L2SRAM.
+
+Necessary Code changes Required:
+=====================================
+Please note that below mentioned changes are for 85xx platforms.
+They have been tested on P1020/P2020/P1010 RDB.
+
+The main difference between the above two methods from technical perspective is
+that in 1st case SOC is just out of reset so it is in default configuration.
+(CCSRBAR is at 0xff700000).
+In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000
+
+1. File name-> boards.cfg
+ There can be added specific Make options for RAMBoot. We can keep different
+ options for the two cases mentioned above.
+ for example
+ P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT.
+
+2. platform config file
+ for example include/configs/P1_P2_RDB.h
+
+ #ifdef CONFIG_RAMBOOT
+ #define CONFIG_SDCARD
+ #endif
+
+ This will finally use the CONFIG_SYS_RAMBOOT.
+
+3. File name-> arch/powerpc/include/asm/config_mpc85xx.h
+ In the section of the particular SOC, for example P1020,
+
+ #if defined(CONFIG_GO)
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000
+ #else
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000
+ #endif
+
+For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000.
diff --git a/marvell/uboot/doc/README.rmobile b/marvell/uboot/doc/README.rmobile
new file mode 100644
index 0000000..4fbbcb3
--- /dev/null
+++ b/marvell/uboot/doc/README.rmobile
@@ -0,0 +1,84 @@
+Summary
+=======
+
+This README is about U-Boot support for Renesas's ARM Cortex-A9 based RMOBILE[1]
+and R-Car[2]family of SoCs. Renesas's RMOBILE/R-Car SoC family contains an ARM
+Cortex-A9.
+
+Currently the following boards are supported:
+
+* KMC KZM-A9-GT [3]
+* Atmark-Techno Armadillo-800-EVA [4]
+* Renesas Electronics Lager
+* Renesas Electronics Koelsch
+
+Toolchain
+=========
+
+ARM Cortex-A9 support ARM v7 instruction set (-march=armv7a).
+But currently we compile with -march=armv5 to allow more compilers to work.
+(For U-Boot code this has no performance impact.)
+Because there was no compiler which is supporting armv7a not much before.
+Currently, ELDK[5], Linaro[6], CodeSourcey[7] and Emdebian[8] supports -march=armv7a
+and you can get.
+
+Build
+=====
+
+* KZM-A9-GT
+
+ make kzm9g_config
+ make
+
+* Armadillo-800-EVA
+
+ make armadillo-800eva_config
+ make
+
+ Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only.
+ Please see "B.2 Appendix B Boot Specifications" in hardware manual.
+
+* Lager
+
+ make lager_config
+ make
+
+* Koelsch
+
+ make koelsch_config
+ make
+
+Links
+=====
+
+[1] Renesas RMOBILE:
+
+http://am.renesas.com/products/soc/assp/mobile/r_mobile/index.jsp
+
+[2] Renesas R-Car:
+
+http://am.renesas.com/products/soc/assp/automotive/index.jsp
+
+[3] KZM-A9-GT
+
+http://www.kmckk.co.jp/kzma9-gt/index.html
+
+[4] Armadillo-800-EVA
+
+http://armadillo.atmark-techno.com/armadillo-800-EVA
+
+[5] ELDK
+
+http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6.
+
+[6] Linaro
+
+http://www.linaro.org/downloads/
+
+[7] CodeSourcey
+
+http://www.mentor.com/embedded-software/codesourcery
+
+[8] Emdebian
+
+http://www.emdebian.org/crosstools.html
diff --git a/marvell/uboot/doc/README.s5pc1xx b/marvell/uboot/doc/README.s5pc1xx
new file mode 100644
index 0000000..ab1f024
--- /dev/null
+++ b/marvell/uboot/doc/README.s5pc1xx
@@ -0,0 +1,72 @@
+
+Summary
+=======
+
+This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx
+family of SoCs (S5PC100 [1] and S5PC110).
+
+Currently the following board is supported:
+
+* SMDKC100 [2]
+
+Toolchain
+=========
+
+While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
+with -march=armv5 to allow more compilers to work. For U-Boot code this has
+no performance impact.
+
+Build
+=====
+
+* SMDKC100
+
+make smdkc100_config
+make
+
+
+Interfaces
+==========
+
+cpu
+
+To check SoC:
+
+ if (cpu_is_s5pc100())
+ printf("cpu is s5pc100\n");
+
+ or
+
+ if (cpu_is_s5pc110())
+ printf("cpu is s5pc110\n");
+
+gpio
+
+ struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE;
+
+ /* GPA[0] pin set to irq */
+ gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ);
+
+ /* GPA[0] pin set to input */
+ gpio_direction_input(&gpio->gpio_a, 0);
+
+ /* GPA[0] pin set to output/high */
+ gpio_direction_output(&gpio->gpio_a, 0, 1);
+
+ /* GPA[0] value set to low */
+ gpio_set_value(&gpio->gpio_a, 0, 0);
+
+ /* get GPA[0] value */
+ value = gpio_get_value(&gpio->gpio_a, 0);
+
+Links
+=====
+
+[1] S5PC100:
+
+http://www.samsung.com/global/business/semiconductor/productInfo.do?
+fmly_id=229&partnum=S5PC100
+
+[2] SMDKC100:
+
+http://meritech.co.kr/eng/products/product_view.php?num=28
diff --git a/marvell/uboot/doc/README.sata b/marvell/uboot/doc/README.sata
new file mode 100644
index 0000000..d0ce667
--- /dev/null
+++ b/marvell/uboot/doc/README.sata
@@ -0,0 +1,68 @@
+1. SATA usage in U-boot
+
+ There are two ways to operate the hard disk
+
+ * Read/write raw blocks from/to SATA hard disk
+ * ext2load to read a file from ext2 file system
+
+1.0 How to read the SATA hard disk's information?
+
+ => sata info
+
+SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN
+ Type: Hard Disk
+ Supports 48-bit addressing
+ Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
+
+1.1 How to raw write the kernel, file system, dtb to a SATA hard disk?
+
+ Notes: Hard disk sectors are normally 512 bytes, so
+ 0x1000 sectors = 2 MBytes
+
+ write kernel
+ => tftp 40000 /tftpboot/uImage.837x
+ => sata write 40000 0 2000
+
+ write ramdisk
+ => tftp 40000 /tftpboot/ramdisk.837x
+ => sata write 40000 2000 8000
+
+ write dtb
+ => tftp 40000 /tftpboot/mpc837xemds.dtb
+ => sata write 40000 a000 1000
+
+1.2 How to raw read the kernel, file system, dtb from a SATA hard disk?
+
+ load kernel
+ => sata read 200000 0 2000
+
+ load ramdisk
+ => sata read 1000000 2000 8000
+
+ load dtb
+ => sata read 2000000 a000 1000
+
+ boot
+ => bootm 200000 1000000 2000000
+
+1.3 How to load an image from an ext2 file system in U-boot?
+
+ U-boot doesn't support writing to an ext2 file system, so the
+ files must be written by other means (e.g. linux).
+
+ => ext2ls sata 0:1 /
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 16384 lost+found
+ 1352023 uImage.837x
+ 3646377 ramdisk.837x
+ 12288 mpc837xemds.dtb
+ 12 hello.txt
+
+ => ext2load sata 0:1 200000 /uImage.837x
+
+ => ext2load sata 0:1 1000000 /ramdisk.837x
+
+ => ext2load sata 0:1 2000000 /mpc837xemds.dtb
+
+ => bootm 200000 1000000 2000000
diff --git a/marvell/uboot/doc/README.sched b/marvell/uboot/doc/README.sched
new file mode 100644
index 0000000..3aa89e6
--- /dev/null
+++ b/marvell/uboot/doc/README.sched
@@ -0,0 +1,53 @@
+Notes on the scheduler in sched.c:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ 'sched.c' provides an very simplistic multi-threading scheduler.
+ See the example, function 'sched(...)', in the same file for its
+ API usage.
+
+ Until an exhaustive testing can be done, the implementation cannot
+ qualify as that of production quality. It works with the example
+ in 'sched.c', it may or may not work in other cases.
+
+
+Limitations:
+~~~~~~~~~~~~
+
+ - There are NO primitives for thread synchronization (locking,
+ notify etc).
+
+ - Only the GPRs and FPRs context is saved during a thread context
+ switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
+ etc) are NOT saved.
+
+ - The scheduler is NOT transparent to the user. The user
+ applications must invoke thread_yield() to allow other threads to
+ scheduler.
+
+ - There are NO priorities, and the scheduling policy is round-robin
+ based.
+
+ - There are NO capabilities to collect thread CPU usage, scheduler
+ stats, thread status etc.
+
+ - The semantics are somewhat based on those of pthreads, but NOT
+ the same.
+
+ - Only seven threads are allowed. These can be easily increased by
+ changing "#define MAX_THREADS" depending on the available memory.
+
+ - The stack size of each thread is 8KBytes. This can be easily
+ increased depending on the requirement and the available memory,
+ by increasing "#define STK_SIZE".
+
+ - Only one master/parent thread is allowed, and it cannot be
+ stopped or deleted. Any given thread is NOT allowed to stop or
+ delete itself.
+
+ - There NOT enough safety checks as are probably in the other
+ threads implementations.
+
+ - There is no parent-child relationship between threads. Only one
+ thread may thread_join, preferably the master/parent thread.
+
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
diff --git a/marvell/uboot/doc/README.scrapyard b/marvell/uboot/doc/README.scrapyard
new file mode 100644
index 0000000..2aed855
--- /dev/null
+++ b/marvell/uboot/doc/README.scrapyard
@@ -0,0 +1,109 @@
+Over time, support for more and more boards gets added to U-Boot -
+while other board support code dies a silent death caused by
+negligence in combination with ordinary bitrot. Sometimes this goes
+by unnoticed, but often build errors will result. If nobody cares any
+more to resolve such problems, then the code is really dead and will
+be removed from the U-Boot source tree. The remainders rest in piece
+in the imperishable depths of the git history. This document tries to
+maintain a list of such former fellows, so archeologists can check
+easily if here is something they might want to dig for...
+
+
+Board Arch CPU Commit Removed Last known maintainer/contact
+=================================================================================================
+mx1ads arm arm920t - 2014-01-13
+mini2440 arm arm920t - 2014-01-13 Gabriel Huau <contact@huau-gabriel.fr>
+omap730p2 arm arm926ejs 79c5c08d 2013-11-11
+pn62 powerpc mpc824x 649acfe1 2013-11-11 Wolfgang Grandegger <wg@grandegger.com>
+pdnb3 arm ixp 304db0b 2013-09-24 Stefan Roese <sr@denx.de>
+scpu arm ixp 304db0b 2013-09-24 Stefan Roese <sr@denx.de>
+omap1510inn arm arm925t 0610a16 2013-09-23 Kshitij Gupta <kshitij@ti.com>
+CANBT powerpc 405CR fb8f4fd 2013-08-07 Matthias Fuchs <matthias.fuchs@esd.eu>
+Alaska8220 powerpc mpc8220 d6ed322 2013-05-11
+Yukon8220 powerpc mpc8220 d6ed322 2013-05-11
+sorcery powerpc mpc8220 d6ed322 2013-05-11
+smdk6400 arm arm1176 52587f1 2013-04-12 Zhong Hongbo <bocui107@gmail.com>
+ns9750dev arm arm926ejs 4cfc611 2013-02-28 Markus Pietrek <mpietrek@fsforth.de>
+AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+c2mon powerpc mpc855 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+EP88x powerpc mpc885 1b0757e 2012-10-28
+ETX094 powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+IAD210 powerpc mpc860 1b0757e 2012-10-28 -
+LANTEC powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+SCM powerpc mpc8260 1b0757e 2012-10-28 Wolfgang Grandegger <wg@denx.de>
+SX1 arm arm925t 53c4154 2012-10-26
+TQM85xx powerpc MPC85xx d923a5d 2012-10-04 Stefan Roese <sr@denx.de>
+apollon arm omap24xx 535c74f 2012-09-18 Kyungmin Park <kyungmin.park@samsung.com>
+tb0229 mips mips32 3f3110d 2011-12-12
+rmu powerpc MPC850 fb82fd7 2011-12-07 Wolfgang Denk <wd@denx.de>
+OXC powerpc MPC8240 309a292 2011-12-07
+BAB7xx powerpc MPC740/MPC750 c53043b 2011-12-07 Frank Gottschling <fgottschling@eltec.de>
+xm250 arm pxa c746cdd 2011-25-11
+pleb2 arm pxa b185a1c 2011-25-11
+cradle arm pxa 4e24f8a 2011-25-11 Kyle Harris <kharris@nexus-tech.net>
+cerf250 arm pxa a3f1241 2011-25-11 Prakash Kumar <prakash@embedx.com>
+mpq101 powerpc mpc85xx e877fab 2011-10-23 Alex Dubov <oakad@yahoo.com>
+ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr@denx.de>
+ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris@nexus-tech.net>
+zylonite arm pxa b66521a 2011-09-05
+shannon arm sa1100 5df092d 2011-09-05 Rolf Offermanns <rof@sysgo.de>
+modnet50 arm arm720t 9c62815 2011-09-05 Thomas Elste <info@elste.org>
+lpc2292sodimm arm arm720t d1a067a 2011-09-05
+lart arm sa1100 3d57573 2011-09-05 Alex Züpke <azu@sysgo.de>
+impa7 arm arm720t c1f8750 2011-09-05 Marius Gröger <mag@sysgo.de>
+gcplus arm sa1100 2c650e2 2011-09-05 George G. Davis <gdavis@mvista.com>
+evb4510 arm arm720t 26e670e 2011-09-05 Curt Brune <curt@cucy.com>
+ep7312 arm arm720t c8f63b4 2011-09-05 Marius Gröger <mag@sysgo.de>
+dnp1110 arm sa1100 fc5e5ce 2011-09-05 Alex Züpke <azu@sysgo.de>
+SMN42 arm arm720t 6aac646 2011-09-05
+at91rm9200dk arm arm920t 1c85752 2011-07-17
+m501sk arm arm920t b1a2bd4 2011-07-17
+kb9202 arm arm920t 5bd3814 2011-07-17
+csb637 arm arm920t d14af08 2011-07-17
+cmc_pu2 arm arm920t 37a9b4d 2011-07-17
+at91cap9adk arm arm926ejs b550834 2011-07-17 Stelian Pop <stelian@popies.net>
+voiceblue arm arm925t 1b793a4 2011-07-17
+smdk2400 arm arm920t ad218a8 2011-07-17 Gary Jennejohn <garyj@denx.de>
+sbc2410x arm arm920t 1f7f0ed 2011-07-17
+netstar arm arm925t 6ea2405 2011-07-17
+mx1fs2 arm arm920t 6962419 2011-07-17
+lpd7a404 arm lh7a40x 957731e 2011-07-17
+edb9301 arm arm920t 716f7ad 2011-07-17
+edb9302 arm arm920t 716f7ad 2011-07-17
+edb9302a arm arm920t 716f7ad 2011-07-17
+edb9307 arm arm920t 716f7ad 2011-07-17
+edb9307a arm arm920t 716f7ad 2011-07-17
+edb9312 arm arm920t 716f7ad 2011-07-17
+edb9315 arm arm920t 716f7ad 2011-07-17
+edb9315a arm arm920t 716f7ad 2011-07-17
+B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian <andrea.scian@dave-tech.it>
+armadillo arm arm720t be28857 2011-07-16 Rowel Atienza <rowel@diwalabs.com>
+assabet arm sa1100 c91e90d 2011-07-16 George G. Davis <gdavis@mvista.com>
+trab arm S3C2400 566e5cf 2011-05-01 Gary Jennejohn <garyj@denx.de>
+xsengine ARM PXA2xx 4262a7c 2010-10-20
+wepep250 ARM PXA2xx 7369478 2010-10-20 Peter Figuli <peposh@etc.sk>
+delta ARM PXA2xx 75e2035 2010-10-20
+mp2usb ARM AT91RM2900 ee986e2 2011-01-25 Eric Bénard <eric@eukrea.com>
+barco powerpc MPC8245 afaa27b 2010-11-23 Marc Leeman <marc.leeman@barco.com>
+ERIC powerpc 405GP d9ba451 2010-11-21 Swen Anderson <sand@peppercon.de>
+VoVPN-GW_100MHz powerpc MPC8260 26fe3d2 2010-10-24 Juergen Selent <j.selent@elmeg.de>
+NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
+CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
+logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl@gmx.at>
+CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg@denx.de>
+PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd@denx.de>
+spieval powerpc MPC5200 69434e4 2010-09-19
+smmaco4 powerpc MPC5200 9ddc3af 2010-09-19
+HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd@denx.de>
+GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas@corelatus.se>
+AmigaOneG3SE powerpc 74xx_7xx 953b7e6 2010-06-23
+suzaku microblaze - 4f18060 2009-10-03 Yasushi Shoji <yashi@atmark-techno.com>
+XUPV2P microblaze - 8fab49e 2008-12-10 Michal Simek <monstr@monstr.eu>
+MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz@matrix-vision.de>
+adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com>
+R5200 ColdFire - 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com>
+CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de>
+PCIPPC6 powerpc MPC740/MPC750 - - Wolfgang Denk <wd@denx.de>
+omap2420h4 arm omap24xx - 2013-06-04 Richard Woodruff <r-woodruff2@ti.com>
+eNET x86 x86 7e8c53d 2013-02-14 Graeme Russ <graeme.russ@gmail.com>
diff --git a/marvell/uboot/doc/README.serial_multi b/marvell/uboot/doc/README.serial_multi
new file mode 100644
index 0000000..ad61d42
--- /dev/null
+++ b/marvell/uboot/doc/README.serial_multi
@@ -0,0 +1,80 @@
+The support for multiple serial interfaces as implemented is mainly
+intended to allow for modem dial-in / dial-out while still being able
+to use a serial console on a (different) serial port.
+
+MPC8XX Specific
+===============
+At the moment, the ports must be split on a SMC and a SCC port on a
+8xx processor; other configurations are not (yet) supported.
+
+Support for hardware handshake has not been implemented yet (but is
+in the works).
+
+*) The default console depends on the keys pressed:
+ - SMC if keys not pressed (modem not enabled)
+ - SCC if keys pressed (modem enabled)
+
+*) The console can be switched to SCC by any of the following commands:
+
+ setenv stdout serial_scc
+ setenv stdin serial_scc
+ setenv stderr serial_scc
+
+*) The console can be switched to SMC by any of the following commands:
+
+ setenv stdout serial_smc
+ setenv stdin serial_smc
+ setenv stderr serial_smc
+
+*) If a file descriptor is set to "serial" then the current serial device
+will be used which, in turn, can be switched by above commands.
+
+*) The baudrate is the same for all serial devices. But it can be switched
+just after switching the console:
+
+ setenv sout serial_scc; setenv baudrate 38400
+
+After that press 'enter' at the SCC console. Note that baudrates <38400
+are not allowed on LWMON with watchdog enabled (see CONFIG_SYS_BAUDRATE_TABLE in
+include/configs/lwmon.h).
+
+
+PPC4XX Specific
+===============
+*) The default console is UART0
+
+*) The console can be switched to UART1 by any of the following commands:
+ setenv stdout serial1
+ setenv stderr serial1
+ setenv stdin serial1
+
+*) The console can be switched to UART0 by any of the following commands:
+ setenv stdout serial0
+ setenv stderr serial0
+ setenv stdin serial0
+
+MPC5xxx Specific
+================
+
+Up to two PSCs can be used as console.
+
+Support for hardware handshake has not been implemented yet.
+
+*) The first (default) console port is defined by:
+ #define CONFIG_PSC_CONSOLE <PSC number>
+
+*) The second (alternative) console port is defined by:
+ #define CONFIG_PSC_CONSOLE2 <PSC number>
+
+*) Commands to switch to the second console:
+ setenv stdout serial1
+ setenv stderr serial1
+ setenv stdin serial1
+
+*) Commands to switch to the first console:
+ setenv stdout serial0
+ setenv stderr serial0
+ setenv stdin serial0
+
+*) If a file descriptor is set to "serial" then the
+ current serial device will be used.
diff --git a/marvell/uboot/doc/README.sh b/marvell/uboot/doc/README.sh
new file mode 100644
index 0000000..6baee08
--- /dev/null
+++ b/marvell/uboot/doc/README.sh
@@ -0,0 +1,104 @@
+
+U-Boot for Renesas SuperH
+ Last update 01/18/2008 by Nobuhiro Iwamatsu
+
+================================================================================
+0. What's this?
+ This file contains status information for the port of U-Boot to the
+ Renesas SuperH series of CPUs.
+
+================================================================================
+1. Overview
+ SuperH has an original boot loader. However, source code is dirty, and
+ maintenance is not done.
+ To improve sharing and the maintenance of the code, Nobuhiro Iwamatsu
+ started the porting to u-boot in 2007.
+
+================================================================================
+2. Supported CPUs
+
+ 2.1. Renesas SH7750/SH7750R
+ This CPU has the SH4 core.
+
+ 2.2. Renesas SH7722
+ This CPU has the SH4AL-DSP core.
+
+ 2.3. Renesas SH7720
+ This CPU has the SH3 core.
+
+ 2.4. Renesas SH7710/SH7712
+ This CPU has the SH3-DSP core and Ethernet controller.
+
+ 2.5. Renesas SH7780
+ This CPU has the SH4A core.
+
+================================================================================
+3. Supported Boards
+
+ 3.1. Hitachi UL MS7750SE01/MS7750RSE01
+ Board specific code is in board/ms7750se
+ To use this board, type "make ms7750se_config".
+ Support devices are :
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+
+ 3.2. Hitachi UL MS7722SE01
+ Board specific code is in board/ms7722se
+ To use this board, type "make ms7722se_config".
+ Support devices are :
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+ - SMC91x ethernet
+
+ 3.2. Hitachi UL MS7720ERP01
+ Board specific code is in board/ms7720se
+ To use this board, type "make ms7720se_config".
+ Support devices are :
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+
+ 3.3. Renesas R7780MP
+ Board specific code is in board/r7780mp
+ To use this board, type "make r7780mp_config".
+ Support devices are :
+ - SCIF
+ - DDR-SDRAM
+ - NOR Flash
+ - Compact Flash
+ - ASIX ethernet
+ - SH7780 PCI bridge
+ - RTL8110 ethernet
+
+ ** README **
+ In SuperH, S-record and binary of made u-boot work on the memory.
+ When u-boot is written in the flash, it is necessary to change the
+ address by using 'objcopy'.
+ ex) shX-linux-objcopy -Ibinary -Osrec u-boot.bin u-boot.flash.srec
+
+================================================================================
+4. Compiler
+ You can use the following of u-boot to compile.
+ - SuperH Linux Open site
+ http://www.superh-linux.org/
+ - KPIT GNU tools
+ http://www.kpitgnutools.com/
+
+================================================================================
+5. Future
+ I plan to support the following CPUs and boards.
+ 5.1. CPUs
+ - SH7751R(SH4)
+ - SH7785(SH4)
+
+ 5.2. Boards
+ - Many boards ;-)
+
+================================================================================
+Copyright (c) 2007,2008
+ Nobuhiro Iwamatsu <iwamatsu@nigaur.org>
diff --git a/marvell/uboot/doc/README.sh7752evb b/marvell/uboot/doc/README.sh7752evb
new file mode 100644
index 0000000..c1fb54c
--- /dev/null
+++ b/marvell/uboot/doc/README.sh7752evb
@@ -0,0 +1,67 @@
+========================================
+Renesas R0P7752C00000RZ board
+========================================
+
+This board specification:
+=========================
+
+The R0P7752C00000RZ(board config name:sh7752evb) has the following device:
+
+ - SH7752 (SH-4A)
+ - DDR3-SDRAM 512MB
+ - SPI ROM 8MB
+ - Gigabit Ethernet controllers
+ - eMMC 4GB
+
+
+Configuration for This board:
+=============================
+
+You can select the configuration as follows:
+
+ - make sh7752evb_config
+
+
+This board specific command:
+============================
+
+This board has the following its specific command:
+
+ - write_mac
+
+
+1. write_mac
+
+You can write MAC address to SPI ROM.
+
+ Usage 1) Write MAC address
+
+ write_mac [GETHERC ch0] [GETHERC ch1]
+
+ For example)
+ => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f
+ *) We have to input the command as a single line
+ (without carriage return)
+ *) We have to reset after input the command.
+
+ Usage 2) Show current data
+
+ write_mac
+
+ For example)
+ => write_mac
+ GETHERC ch0 = 74:90:50:00:33:9e
+ GETHERC ch1 = 74:90:50:00:33:9f
+
+
+Update SPI ROM:
+============================
+
+1. Copy u-boot image to RAM area.
+2. Probe SPI device.
+ => sf probe 0
+ SF: Detected MX25L6405D with page size 64KiB, total 8 MiB
+3. Erase SPI ROM.
+ => sf erase 0 80000
+4. Write u-boot image to SPI ROM.
+ => sf write 0x48000000 0 80000
diff --git a/marvell/uboot/doc/README.sh7753evb b/marvell/uboot/doc/README.sh7753evb
new file mode 100644
index 0000000..5fe178c
--- /dev/null
+++ b/marvell/uboot/doc/README.sh7753evb
@@ -0,0 +1,67 @@
+========================================
+Renesas SH7753 EVB board
+========================================
+
+This board specification:
+=========================
+
+The SH7753 EVB (board config name:sh7753evb) has the following device:
+
+ - SH7753 (SH-4A)
+ - DDR3-SDRAM 512MB
+ - SPI ROM 8MB
+ - Gigabit Ethernet controllers
+ - eMMC 4GB
+
+
+Configuration for This board:
+=============================
+
+You can select the configuration as follows:
+
+ - make sh7753evb_config
+
+
+This board specific command:
+============================
+
+This board has the following its specific command:
+
+ - write_mac
+
+
+1. write_mac
+
+You can write MAC address to SPI ROM.
+
+ Usage 1) Write MAC address
+
+ write_mac [GETHERC ch0] [GETHERC ch1]
+
+ For example)
+ => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f
+ *) We have to input the command as a single line
+ (without carriage return)
+ *) We have to reset after input the command.
+
+ Usage 2) Show current data
+
+ write_mac
+
+ For example)
+ => write_mac
+ GETHERC ch0 = 74:90:50:00:33:9e
+ GETHERC ch1 = 74:90:50:00:33:9f
+
+
+Update SPI ROM:
+============================
+
+1. Copy u-boot image to RAM area.
+2. Probe SPI device.
+ => sf probe 0
+ SF: Detected MX25L6405D with page size 64KiB, total 8 MiB
+3. Erase SPI ROM.
+ => sf erase 0 80000
+4. Write u-boot image to SPI ROM.
+ => sf write 0x48000000 0 80000
diff --git a/marvell/uboot/doc/README.sha1 b/marvell/uboot/doc/README.sha1
new file mode 100644
index 0000000..f6cca40
--- /dev/null
+++ b/marvell/uboot/doc/README.sha1
@@ -0,0 +1,57 @@
+SHA1 usage:
+-----------
+
+In the U-Boot Image for the pcs440ep board is a SHA1 checksum integrated.
+This SHA1 sum is used, to check, if the U-Boot Image in Flash is not
+corrupted.
+
+The following command is available:
+
+=> help sha1
+sha1 address len [addr] calculate the SHA1 sum [save at addr]
+ -p calculate the SHA1 sum from the U-Boot image in flash and print
+ -c check the U-Boot image in flash
+
+"sha1 -p"
+ calculates and prints the SHA1 sum, from the Image stored in Flash
+
+"sha1 -c"
+ check, if the SHA1 sum from the Image stored in Flash is correct
+
+
+It is possible to calculate a SHA1 checksum from a memoryrange with:
+
+"sha1 address len"
+
+If you want to store a new Image in Flash for the pcs440ep board,
+which has no SHA1 sum, you can do the following:
+
+a) cp the new Image on a position in RAM (here 0x300000)
+ (for this example we use the Image from Flash, stored at 0xfffa0000 and
+ 0x60000 Bytes long)
+
+"cp.b fffa0000 300000 60000"
+
+b) Initialize the SHA1 sum in the Image with 0x00
+ The SHA1 sum is stored in Flash at:
+ CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN + SHA1_SUM_POS
+ for the pcs440ep Flash: 0xfffa0000 + 0x60000 + -0x20
+ = 0xffffffe0
+ for the example in RAM: 0x300000 + 0x60000 + -0x20
+ = 0x35ffe0
+
+ note: a SHA1 checksum is 20 bytes long.
+
+"mw.b 35ffe0 0 14"
+
+c) now calculate the SHA1 sum from the memoryrange and write
+ the calculated checksum at the right place:
+
+"sha1 300000 60000 35ffe0"
+
+Now you have a U-Boot-Image for the pcs440ep board with the correct SHA1 sum.
+
+If you do a "./MAKEALL pcs440ep" or a "make all" to get the U-Boot image,
+the correct SHA1 sum will be automagically included in the U-Boot image.
+
+Heiko Schocher, 11 Jul 2007
diff --git a/marvell/uboot/doc/README.silent b/marvell/uboot/doc/README.silent
new file mode 100644
index 0000000..6d90a0e
--- /dev/null
+++ b/marvell/uboot/doc/README.silent
@@ -0,0 +1,28 @@
+The config option CONFIG_SILENT_CONSOLE can be used to quiet messages
+on the console. If the option has been enabled, the output can be
+silenced by setting the environment variable "silent".
+
+- CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
+ When the "silent" variable is changed with env set, the change
+ will take effect immediately.
+
+- CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC
+ Some environments are not available until relocation (e.g. NAND)
+ so this will make the value in the flash env take effect at
+ relocation.
+
+The following actions are taken if "silent" is set at boot time:
+
+ - Until the console devices have been initialized, output has to be
+ suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags".
+
+ - When the console devices have been initialized, "stdout" and
+ "stderr" are set to "nulldev", so subsequent messages are
+ suppressed automatically. Make sure to enable "nulldev" by
+ #defining CONFIG_SYS_DEVICE_NULLDEV in your board config file.
+
+ - When booting a linux kernel, the "bootargs" are fixed up so that
+ the argument "console=" will be in the command line, no matter how
+ it was set in "bootargs" before. If you don't want the linux command
+ line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board
+ config file as well, and this part of the feature will be disabled.
diff --git a/marvell/uboot/doc/README.socfpga b/marvell/uboot/doc/README.socfpga
new file mode 100644
index 0000000..cfcbbfe
--- /dev/null
+++ b/marvell/uboot/doc/README.socfpga
@@ -0,0 +1,53 @@
+
+--------------------------------------------
+SOCFPGA Documentation for U-Boot and SPL
+--------------------------------------------
+
+This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore
+based SOCFPGA. To know more about the hardware itself, please refer to
+www.altera.com.
+
+
+--------------------------------------------
+socfpga_dw_mmc
+--------------------------------------------
+Here are macro and detailed configuration required to enable DesignWare SDMMC
+controller support within SOCFPGA
+
+#define CONFIG_MMC
+-> To enable the SD MMC framework support
+
+#define CONFIG_SDMMC_BASE (SOCFPGA_SDMMC_ADDRESS)
+-> The base address of CSR register for DesignWare SDMMC controller
+
+#define CONFIG_GENERIC_MMC
+-> Enable the generic MMC driver
+
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT 256
+-> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM
+
+#define CONFIG_DWMMC
+-> Enable the common DesignWare SDMMC controller framework
+
+#define CONFIG_SOCFPGA_DWMMC
+-> Enable the SOCFPGA specific driver for DesignWare SDMMC controller
+
+#define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH 1024
+-> The FIFO depth for SOCFPGA DesignWare SDMMC controller
+
+#define CONFIG_SOCFPGA_DWMMC_DRVSEL 3
+-> Phase-shifted clock of sdmmc_clk for controller to drive command and data to
+the card to meet hold time requirements. SD clock is running at 50MHz and
+drvsel is set to shift 135 degrees (3 * 45 degrees). With that, the hold time
+is 135 / 360 * 20ns = 7.5ns.
+
+#define CONFIG_SOCFPGA_DWMMC_SMPSEL 0
+-> Phase-shifted clock of sdmmc_clk used to sample the command and data from
+the card
+
+#define CONFIG_SOCFPGA_DWMMC_BUS_WIDTH 4
+-> Bus width of data line which either 1, 4 or 8 and based on board routing.
+
+#define CONFIG_SOCFPGA_DWMMC_BUS_HZ 50000000
+-> The clock rate to controller. Do note the controller have a wrapper which
+divide the clock from PLL by 4.
diff --git a/marvell/uboot/doc/README.spear b/marvell/uboot/doc/README.spear
new file mode 100644
index 0000000..0789b3f
--- /dev/null
+++ b/marvell/uboot/doc/README.spear
@@ -0,0 +1,74 @@
+
+SPEAr (Structured Processor Enhanced Architecture).
+
+SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic
+
+The SPEAr SoC family embeds a customizable logic that can be programmed
+one-time by a customer at silicon mask level (i.e. not at runtime!).
+
+U-Boot supports four SoCs: SPEAr600, SPEAr3xx
+
+All 4 SoCs (SPEAr3xx and SPEAr600) share common peripherals. SPEAr300 and
+SPEAr600 do not have EMI.
+
+1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux)
+2. FastEthernet (sp600 has Gbit version, but same controller - GMAC)
+3. USB Host
+4. USB Device
+5. NAND controller (FSMC)
+6. Serial NOR ctrl
+7. I2C
+8. SPI
+9. CLCD
+10. others ..
+
+Everything is supported in Linux.
+u-boot is currently not supporting all peripeharls (just a few as listed below).
+1. USB Device
+2. NAND controller (FSMC)
+3. Serial Memory Interface
+4. EMI (Parallel NOR interface)
+4. I2C
+5. UART
+
+Build options
+ make spear320_config
+ spear320 build with environment variables placed at default
+ location i.e. Serial NOR device
+ make spear320_pnor_config
+ This option generates a uboot image that supports emi controller
+ for CFI compliant parallel NOR flash. Environment variables are
+ placed in Parallel NOR device
+ make spear320_nand_config
+ spear320 build with environment variables placed in NAND device
+ make spear320_usbtty_config
+ spear320 build with usbtty terminal as default and environment
+ placed at default location
+ make spear320_usbtty_pnor_config
+ spear320 build with usbtty terminal as default and environment
+ placed in pnor device
+ make spear320_usbtty_nand_config
+ Build with usbtty terminal as default and environment placed in
+ NAND device
+ make spear300_config
+ make spear300_nand_config
+ make spear300_usbtty_config
+ make spear300_usbtty_nand_config
+ make spear310_config
+ make spear310_pnor_config
+ make spear310_nand_config
+ make spear310_usbtty_config
+ make spear310_usbtty_pnor_config
+ make spear310_usbtty_nand_config
+ make spear600_config
+ make spear600_nand_config
+ make spear600_usbtty_config
+ make spear600_usbtty_nand_config
+
+Mac id storage and retrieval in spear platforms
+
+Please read doc/README.enetaddr for the implementation guidelines for mac id
+usage. Basically, environment has precedence over board specific storage. The
+ethaddr beeing used for the network interface is always taken only from
+environment variables. Although, we can check the mac id programmed in i2c
+memory by using chip_config command
diff --git a/marvell/uboot/doc/README.splashprepare b/marvell/uboot/doc/README.splashprepare
new file mode 100644
index 0000000..61b4ec5
--- /dev/null
+++ b/marvell/uboot/doc/README.splashprepare
@@ -0,0 +1,8 @@
+---------------------------------------------------------------------
+Splash Screen
+---------------------------------------------------------------------
+The splash_screen_prepare() function is a weak function defined in
+common/splash.c. It is called as part of the splash screen display
+sequence. It gives the board an opportunity to prepare the splash
+image data before it is processed and sent to the frame buffer by
+U-Boot. Define your own version to use this feature.
diff --git a/marvell/uboot/doc/README.srio-pcie-boot-corenet b/marvell/uboot/doc/README.srio-pcie-boot-corenet
new file mode 100644
index 0000000..2b1f76b
--- /dev/null
+++ b/marvell/uboot/doc/README.srio-pcie-boot-corenet
@@ -0,0 +1,118 @@
+---------------------------------------
+SRIO and PCIE Boot on Corenet Platforms
+---------------------------------------
+
+For some PowerPC processors with SRIO or PCIE interface, boot location can be
+configured to SRIO or PCIE by RCW. The processor booting from SRIO or PCIE can
+do without flash for u-boot image, ucode and ENV. All the images can be fetched
+from another processor's memory space by SRIO or PCIE link connected between
+them.
+
+This document describes the processes based on an example implemented on P4080DS
+platforms and a RCW example with boot from SRIO or PCIE configuration.
+
+Environment of the SRIO or PCIE boot:
+ a) Master and slave can be SOCs in one board or SOCs in separate boards.
+ b) They are connected with SRIO or PCIE links, whether 1x, 2x or 4x, and
+ directly or through switch system.
+ c) Only Master has NorFlash for booting, and all the Master's and Slave's
+ U-Boot images, UCodes will be stored in this flash.
+ d) Slave has its own EEPROM for RCW and PBI.
+ e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set
+ the boot location to SRIO or PCIE, and holdoff all the cores.
+
+ ----------- ----------- -----------
+ | | | | | |
+ | | | | | |
+ | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM]
+ | | | |<===========>| |
+ | | | | | |
+ ----------- ----------- -----------
+
+The example based on P4080DS platform:
+ Two P4080DS platforms can be used to implement the boot from SRIO or PCIE.
+ Their SRIO or PCIE ports 1 will be connected directly and will be used for
+ the boot from SRIO or PCIE.
+
+ 1. Slave's RCW example for boot from SRIO port 1 and all cores in holdoff.
+ 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
+ 00000010: 1818 1818 0000 8888 7440 4000 0000 2000
+ 00000020: f440 0000 0100 0000 0000 0000 0000 0000
+ 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
+ 00000040: 0000 0000 0000 0000 0813 8040 063c 778f
+
+ 2. Slave's RCW example for boot from PCIE port 1 and all cores in holdoff.
+ 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
+ 00000010: 1818 1818 0000 8888 1440 4000 0000 2000
+ 00000020: f040 0000 0100 0000 0020 0000 0000 0000
+ 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
+ 00000040: 0000 0000 0000 0000 0813 8040 547e ffc9
+
+ 3. Sequence in Step by Step.
+ a) Update RCW for slave with boot from SRIO or PCIE port 1 configuration.
+ b) Program slave's U-Boot image, UCode, and ENV parameters into master's
+ NorFlash.
+ c) Set environment variable "bootmaster" to "SRIO1" or "PCIE1" and save
+ environment for master.
+ setenv bootmaster SRIO1
+ or
+ setenv bootmaster PCIE1
+ saveenv
+ d) Restart up master and it will boot up normally from its NorFlash.
+ Then, it will finish necessary configurations for slave's boot from
+ SRIO or PCIE port 1.
+ e) Master will set inbound SRIO or PCIE windows covered slave's U-Boot
+ image stored in master's NorFlash.
+ f) Master will set an inbound SRIO or PCIE window covered slave's UCode
+ and ENV stored in master's NorFlash.
+ g) Master will set outbound SRIO or PCIE windows in order to configure
+ slave's registers for the core's releasing.
+ h) Since all cores of slave in holdoff, slave should be powered on before
+ all the above master's steps, and wait to be released by master. In the
+ startup phase of the slave from SRIO or PCIE, it will finish some
+ necessary configurations.
+ i) Slave will set a specific TLB entry for the boot process.
+ j) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
+ the boot.
+ k) Slave will set a specific TLB entry in order to fetch UCode and ENV
+ from master.
+ l) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
+ UCode and ENV.
+
+How to use this feature:
+ To use this feature, you need to focus those points.
+
+ 1. Slave's RCW with SRIO or PCIE boot configurations, and all cores in holdoff
+ configurations.
+ Please refer to the examples given above.
+
+ 2. U-Boot image's compilation.
+ For master, U-Boot image should be generated normally.
+
+ For example, master U-Boot image used on P4080DS should be compiled with
+
+ make P4080DS_config.
+
+ For slave, U-Boot image should be generated specifically by
+
+ make xxxx_SRIO_PCIE_BOOT_config.
+
+ For example, slave U-Boot image used on P4080DS should be compiled with
+
+ make P4080DS_SRIO_PCIE_BOOT_config.
+
+ 3. Necessary modifications based on a specific environment.
+ For a specific environment, the addresses of the slave's U-Boot image,
+ UCode, ENV stored in master's NorFlash, and any other configurations
+ can be modified in the file:
+ include/configs/corenet_ds.h.
+
+ 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2"
+ or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to
+ perform the role as a master for boot from SRIO or PCIE.
+
+NOTE: When the Slave's ENV parameters are stored in Master's NorFlash,
+ it can fetch them through PCIE or SRIO interface. But the ENV
+ parameters can not be modified by "saveenv" or other commands under
+ the Slave's u-boot environment, because the Slave can not erase,
+ write Master's NorFlash by PCIE or SRIO link.
diff --git a/marvell/uboot/doc/README.standalone b/marvell/uboot/doc/README.standalone
new file mode 100644
index 0000000..2be5f27
--- /dev/null
+++ b/marvell/uboot/doc/README.standalone
@@ -0,0 +1,100 @@
+Design Notes on Exporting U-Boot Functions to Standalone Applications:
+======================================================================
+
+1. The functions are exported by U-Boot via a jump table. The jump
+ table is allocated and initialized in the jumptable_init() routine
+ (common/exports.c). Other routines may also modify the jump table,
+ however. The jump table can be accessed as the 'jt' field of the
+ 'global_data' structure. The slot numbers for the jump table are
+ defined in the <include/exports.h> header. E.g., to substitute the
+ malloc() and free() functions that will be available to standalone
+ applications, one should do the following:
+
+ DECLARE_GLOBAL_DATA_PTR;
+
+ gd->jt[XF_malloc] = my_malloc;
+ gd->jt[XF_free] = my_free;
+
+ Note that the pointers to the functions all have 'void *' type and
+ thus the compiler cannot perform type checks on these assignments.
+
+2. The pointer to the jump table is passed to the application in a
+ machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II
+ architectures use a dedicated register to hold the pointer to the
+ 'global_data' structure: r2 on PowerPC, r8 on ARM, k0 on MIPS,
+ P3 on Blackfin and gp on Nios II. The x86 architecture does not
+ use such a register; instead, the pointer to the 'global_data'
+ structure is passed as 'argv[-1]' pointer.
+
+ The application can access the 'global_data' structure in the same
+ way as U-Boot does:
+
+ DECLARE_GLOBAL_DATA_PTR;
+
+ printf("U-Boot relocation offset: %x\n", gd->reloc_off);
+
+3. The application should call the app_startup() function before any
+ call to the exported functions. Also, implementor of the
+ application may want to check the version of the ABI provided by
+ U-Boot. To facilitate this, a get_version() function is exported
+ that returns the ABI version of the running U-Boot. I.e., a
+ typical application startup may look like this:
+
+ int my_app (int argc, char * const argv[])
+ {
+ app_startup (argv);
+ if (get_version () != XF_VERSION)
+ return 1;
+ }
+
+4. The default load and start addresses of the applications are as
+ follows:
+
+ Load address Start address
+ x86 0x00040000 0x00040000
+ PowerPC 0x00040000 0x00040004
+ ARM 0x0c100000 0x0c100000
+ MIPS 0x80200000 0x80200000
+ Blackfin 0x00001000 0x00001000
+ NDS32 0x00300000 0x00300000
+ Nios II 0x02000000 0x02000000
+
+ For example, the "hello world" application may be loaded and
+ executed on a PowerPC board with the following commands:
+
+ => tftp 0x40000 hello_world.bin
+ => go 0x40004
+
+5. To export some additional function foobar(), the following steps
+ should be undertaken:
+
+ - Append the following line at the end of the include/_exports.h
+ file:
+
+ EXPORT_FUNC(foobar)
+
+ - Add the prototype for this function to the include/exports.h
+ file:
+
+ void foobar(void);
+
+ - Add the initialization of the jump table slot wherever
+ appropriate (most likely, to the jumptable_init() function):
+
+ gd->jt[XF_foobar] = foobar;
+
+ - Increase the XF_VERSION value by one in the include/exports.h
+ file
+
+6. The code for exporting the U-Boot functions to applications is
+ mostly machine-independent. The only places written in assembly
+ language are stub functions that perform the jump through the jump
+ table. That said, to port this code to a new architecture, the
+ only thing to be provided is the code in the examples/stubs.c
+ file. If this architecture, however, uses some uncommon method of
+ passing the 'global_data' pointer (like x86 does), one should add
+ the respective code to the app_startup() function in that file.
+
+ Note that these functions may only use call-clobbered registers;
+ those registers that are used to pass the function's arguments,
+ the stack contents and the return address should be left intact.
diff --git a/marvell/uboot/doc/README.switch_config b/marvell/uboot/doc/README.switch_config
new file mode 100644
index 0000000..f890373
--- /dev/null
+++ b/marvell/uboot/doc/README.switch_config
@@ -0,0 +1,25 @@
+On the enbw_cmc board is a KSZ8864RMN switch which needs
+configured through spi before working. This is done on
+startup from u-boot through a config file stored at an
+address specified in the "hwconfig" environment variable,
+subcommand "config".
+
+For example on the enbw_cmc board:
+
+hwconfig=switch:lan=on,pwl=off,config=0x60160000
+
+The file has the following structure:
+
+- a comment starts with a '#' or a ';' and ends with a newline
+- The switch needs for its config a reg/value pair, so we
+ have two columns in the file:
+ reg : contains the register address
+ value: contains a 8 bit register value
+ This 2 columns are seperated through space or tab.
+
+example (minimal configuration on the enbw_cmc board):
+
+;reg value comment
+;-----------------------------------------
+0x01 0x00
+0x01 0x01 ; Start Switch with this configuration
diff --git a/marvell/uboot/doc/README.t4240qds b/marvell/uboot/doc/README.t4240qds
new file mode 100644
index 0000000..a9841fb
--- /dev/null
+++ b/marvell/uboot/doc/README.t4240qds
@@ -0,0 +1,122 @@
+Overview
+--------
+The T4240QDS is a high-performance computing evaluation, development and test
+platform supporting the T4240 QorIQ™ Power Architecture™ processor. T4240QDS is
+optimized to support the high-bandwidth DDR3 memory ports, as well as the
+highly-configurable SerDes ports. The system is lead-free and RoHS-compliant.
+
+Board Features
+ SERDES Connections
+ 32 lanes grouped into four 8-lane banks
+ Two “front side” banks dedicated to Ethernet
+ - High-speed crosspoint switch fabric on selected lanes
+ - Two PCI Express slots with side-band connector supporting
+ - SGMII
+ - XAUI
+ - HiGig
+ - I-pass connectors allow board-to-board and loopback support
+ Two “back side” banks dedicated to other protocols
+ - High-speed crosspoint switch fabric on all lanes
+ - Four PCI Express slots with side-band connector supporting
+ - PCI Express 3.0
+ - SATA 2.0
+ - SRIO 2.0
+ - Supports 4X Aurora debug with two connectors
+ DDR Controllers
+ Three independant 64-bit DDR3 controllers
+ Supports rates of 1866 up to 2133 MHz data-rate
+ Supports two DDR3/DDR3LP UDIMM/RDIMMs per controller
+ DDR power supplies 1.5V to all devices with automatic tracking of VTT.
+ Power software-switchable to 1.35V if software detects all DDR3LP devices.
+ MT9JSF25672AZ-2G1KZESZF has been tested at 1333, 1600, 1867, 2000 and
+ 2133MT/s speeds. For 1867MT/s and above, read-to-write turnaround time
+ increases by 1 clock.
+
+ IFC/Local Bus
+ NAND flash: 8-bit, async or sync, up to 2GB.
+ NOR: 16-bit, Address/Data Multiplexed (ADM), up to 128 MB
+ NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
+ - NOR devices support 16 virtual banks
+ GASIC: Minimal target within Qixis FPGA
+ PromJET rapid memory download support
+ Address demultiplexing handled within FPGA.
+ - Flexible demux allows 8 or 16 bit evaluation.
+ IFC Debug/Development card
+ - Support for 32-bit devices
+ Ethernet
+ Support two on-board RGMII 10/100/1G ethernet ports.
+ SGMII and XAUI support via SERDES block (see above).
+ 1588 support via Symmetricom board.
+ QIXIS System Logic FPGA
+ Manages system power and reset sequencing
+ Manages DUT, board, clock, etc. configuration for dynamic shmoo
+ Collects V-I-T data in background for code/power profiling.
+ Supports legacy TMT test features (POSt, IRS, SYSCLK-synchronous assertion)
+ General fault monitoring and logging
+ Runs from ATX “hot” power rails allowing operation while system is off.
+ Clocks
+ System and DDR clock (SYSCLK, “DDRCLK”)
+ - Switch selectable to one of 16 common settings in the interval 33MHz-166MHz.
+ - Software selectable in 1MHz increments from 1-200MHz.
+ SERDES clocks
+ - Provides clocks to all SerDes blocks and slots
+ - 100, 125 and 156.25 MHz
+ Power Supplies
+ Dedicated regulators for VDD
+ - Adjustable from (0.7V to 1.3V at 80A
+ - Regulators can be controlled by VID and/or software
+ Dedicated regulator for GVDD_PL: 1.35/1.5V at 22A
+ - VTT/MVREF automatically track operating voltage
+ Dedicated regulators/filters for AVDD supplies
+ Dedicated regulators for other supplies: OVDD, BVDD, DVDD, LVDD, POVDD, etc.
+ USB
+ Supports two USB 2.0 ports with integrated PHYs
+ - One type A, one type micro-AB with 1.0A power per port.
+ Other IO
+ eSDHC/MMC
+ - SDHC card slot
+ eSPI port
+ - High-speed serial flash
+ Two Serial port
+ Four I2C ports
+
+Memory map
+----------
+The addresses in brackets are physical addresses.
+
+0x0_0000_0000 (0x0_0000_0000) - 0x0_7fff_ffff 2GB DDR (more than 2GB is initialized but not mapped under with TLB)
+0x0_8000_0000 (0xc_0000_0000) - 0x0_dfff_ffff 1.5GB PCIE memory
+0x0_f000_0000 (0xf_0000_0000) - 0x0_f1ff_ffff 32MB DCSR (includes trace buffers)
+0x0_f400_0000 (0xf_f400_0000) - 0x0_f5ff_ffff 32MB BMan
+0x0_f600_0000 (0xf_f600_0000) - 0x0_f7ff_ffff 32MB QMan
+0x0_f800_0000 (0xf_f800_0000) - 0x0_f803_ffff 256KB PCIE IO
+0x0_e000_0000 (0xf_e000_0000) - 0x0_efff_ffff 256MB NOR flash
+0x0_fe00_0000 (0xf_fe00_0000) - 0x0_feff_ffff 16MB CCSR
+0x0_ffdf_0000 (0xf_ffdf_0000) - 0x0_ffdf_03ff 4KB QIXIS
+0x0_ffff_f000 (0x0_7fff_fff0) - 0x0_ffff_ffff 4KB Boot page translation for secondary cores
+
+The physical address of the last (boot page translation) varies with the actual DDR size.
+
+Voltage ID and VDD override
+--------------------
+T4240 has a VID feature. U-boot reads the VID efuses and adjust the voltage
+accordingly. The voltage can also be override by command vdd_override. The
+syntax is
+
+vdd_override <voltage in mV>, eg. 1050 is for 1.050v.
+
+Upon success, the actual voltage will be read back. The value is checked
+for safety and any invalid value will not adjust the voltage.
+
+Another way to override VDD is to use environmental variable, in case of using
+command is too late for some debugging. The syntax is
+
+setenv t4240qds_vdd_mv <voltage in mV>
+saveenv
+reset
+
+The override voltage takes effect when booting.
+
+Note: voltage adjustment needs to be done step by step. Changing voltage too
+rapidly may cause current surge. The voltage stepping is done by software.
+Users can set the final voltage directly.
diff --git a/marvell/uboot/doc/README.trace b/marvell/uboot/doc/README.trace
new file mode 100644
index 0000000..f0c9699
--- /dev/null
+++ b/marvell/uboot/doc/README.trace
@@ -0,0 +1,348 @@
+#
+# Copyright (c) 2013 The Chromium OS Authors.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+Tracing in U-Boot
+=================
+
+U-Boot supports a simple tracing feature which allows a record of excecution
+to be collected and sent to a host machine for analysis. At present the
+main use for this is to profile boot time.
+
+
+Overview
+--------
+
+The trace feature uses GCC's instrument-functions feature to trace all
+function entry/exit points. These are then recorded in a memory buffer.
+The memory buffer can be saved to the host over a network link using
+tftpput or by writing to an attached memory device such as MMC.
+
+On the host, the file is first converted with a tool called 'proftool',
+which extracts useful information from it. The resulting trace output
+resembles that emitted by Linux's ftrace feature, so can be visually
+displayed by pytimechart.
+
+
+Quick-start using Sandbox
+-------------------------
+
+Sandbox is a build of U-Boot that can run under Linux so it is a convenient
+way of trying out tracing before you use it on your actual board. To do
+this, follow these steps:
+
+Add the following to include/configs/sandbox.h (if not already there)
+
+#define CONFIG_TRACE
+#define CONFIG_CMD_TRACE
+#define CONFIG_TRACE_BUFFER_SIZE (16 << 20)
+#define CONFIG_TRACE_EARLY_SIZE (8 << 20)
+#define CONFIG_TRACE_EARLY
+#define CONFIG_TRACE_EARLY_ADDR 0x00100000
+
+Build sandbox U-Boot with tracing enabled:
+
+$ make FTRACE=1 O=sandbox sandbox_config
+$ make FTRACE=1 O=sandbox
+
+Run sandbox, wait for a bit of trace information to appear, and then capture
+a trace:
+
+$ ./sandbox/u-boot
+
+
+U-Boot 2013.04-rc2-00100-ga72fcef (Apr 17 2013 - 19:25:24)
+
+DRAM: 128 MiB
+trace: enabled
+Using default environment
+
+In: serial
+Out: serial
+Err: serial
+=>trace stats
+ 671,406 function sites
+ 69,712 function calls
+ 0 untracked function calls
+ 73,373 traced function calls
+ 16 maximum observed call depth
+ 15 call depth limit
+ 66,491 calls not traced due to depth
+=>trace stats
+ 671,406 function sites
+ 1,279,450 function calls
+ 0 untracked function calls
+ 950,490 traced function calls (333217 dropped due to overflow)
+ 16 maximum observed call depth
+ 15 call depth limit
+ 1,275,767 calls not traced due to depth
+=>trace calls 0 e00000
+Call list dumped to 00000000, size 0xae0a40
+=>print
+baudrate=115200
+profbase=0
+profoffset=ae0a40
+profsize=e00000
+stderr=serial
+stdin=serial
+stdout=serial
+
+Environment size: 117/8188 bytes
+=>sb save host 0 trace 0 ${profoffset}
+11405888 bytes written in 10 ms (1.1 GiB/s)
+=>reset
+
+
+Then run proftool to convert the trace information to ftrace format.
+
+$ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt
+
+Finally run pytimechart to display it:
+
+$ pytimechart trace.txt
+
+Using this tool you can zoom and pan across the trace, with the function
+calls on the left and little marks representing the start and end of each
+function.
+
+
+CONFIG Options
+--------------
+
+- CONFIG_TRACE
+ Enables the trace feature in U-Boot.
+
+- CONFIG_CMD_TRACE
+ Enables the trace command.
+
+- CONFIG_TRACE_BUFFER_SIZE
+ Size of trace buffer to allocate for U-Boot. This buffer is
+ used after relocation, as a place to put function tracing
+ information. The address of the buffer is determined by
+ the relocation code.
+
+- CONFIG_TRACE_EARLY
+ Define this to start tracing early, before relocation.
+
+- CONFIG_TRACE_EARLY_SIZE
+ Size of 'early' trace buffer. Before U-Boot has relocated
+ it doesn't have a proper trace buffer. On many boards
+ you can define an area of memory to use for the trace
+ buffer until the 'real' trace buffer is available after
+ relocation. The contents of this buffer are then copied to
+ the real buffer.
+
+- CONFIG_TRACE_EARLY_ADDR
+ Address of early trace buffer
+
+
+Building U-Boot with Tracing Enabled
+------------------------------------
+
+Pass 'FTRACE=1' to the U-Boot Makefile to actually instrument the code.
+This is kept as a separate option so that it is easy to enable/disable
+instrumenting from the command line instead of having to change board
+config files.
+
+
+Collecting Trace Data
+---------------------
+
+When you run U-Boot on your board it will collect trace data up to the
+limit of the trace buffer size you have specified. Once that is exhausted
+no more data will be collected.
+
+Collecting trace data has an affect on execution time/performance. You
+will notice this particularly with trvial functions - the overhead of
+recording their execution may even exceed their normal execution time.
+In practice this doesn't matter much so long as you are aware of the
+effect. Once you have done your optimisations, turn off tracing before
+doing end-to-end timing.
+
+The best time to start tracing is right at the beginning of U-Boot. The
+best time to stop tracing is right at the end. In practice it is hard
+to achieve these ideals.
+
+This implementation enables tracing early in board_init_f(). This means
+that it captures most of the board init process, missing only the
+early architecture-specific init. However, it also misses the entire
+SPL stage if there is one.
+
+U-Boot typically ends with a 'bootm' command which loads and runs an
+OS. There is useful trace data in the execution of that bootm
+command. Therefore this implementation provides a way to collect trace
+data after bootm has finished processing, but just before it jumps to
+the OS. In practical terms, U-Boot runs the 'fakegocmd' environment
+variable at this point. This variable should have a short script which
+collects the trace data and writes it somewhere.
+
+Trace data collection relies on a microsecond timer, accesed through
+timer_get_us(). So the first think you should do is make sure that
+this produces sensible results for your board. Suitable sources for
+this timer include high resolution timers, PWMs or profile timers if
+available. Most modern SOCs have a suitable timer for this. Make sure
+that you mark this timer (and anything it calls) with
+__attribute__((no_instrument_function)) so that the trace library can
+use it without causing an infinite loop.
+
+
+Commands
+--------
+
+The trace command has variable sub-commands:
+
+- stats
+ Display tracing statistics
+
+- pause
+ Pause tracing
+
+- resume
+ Resume tracing
+
+- funclist [<addr> <size>]
+ Dump a list of functions into the buffer
+
+- calls [<addr> <size>]
+ Dump function call trace into buffer
+
+If the address and size are not given, these are obtained from environment
+variables (see below). In any case the environment variables are updated
+after the command runs.
+
+
+Environment Variables
+---------------------
+
+The following are used:
+
+- profbase
+ Base address of trace output buffer
+
+- profoffset
+ Offset of first unwritten byte in trace output buffer
+
+- profsize
+ Size of trace output buffer
+
+All of these are set by the 'trace calls' command.
+
+These variables keep track of the amount of data written to the trace
+output buffer by the 'trace' command. The trace commands which write data
+to the output buffer can use these to specify the buffer to write to, and
+update profoffset each time. This allows successive commands to append data
+to the same buffer, for example:
+
+ trace funclist 10000 e00000
+ trace calls
+
+(the latter command appends more data to the buffer).
+
+
+- fakegocmd
+ Specifies commands to run just before booting the OS. This
+ is a useful time to write the trace data to the host for
+ processing.
+
+
+Writing Out Trace Data
+----------------------
+
+Once the trace data is in an output buffer in memory there are various ways
+to transmit it to the host. Notably you can use tftput to send the data
+over a network link:
+
+fakegocmd=trace pause; usb start; set autoload n; bootp;
+ trace calls 10000000 1000000;
+ tftpput ${profbase} ${profoffset} 192.168.1.4:/tftpboot/calls
+
+This starts up USB (to talk to an attached USB Ethernet dongle), writes
+a trace log to address 10000000 and sends it to a host machine using
+TFTP. After this, U-Boot will boot the OS normally, albeit a little
+later.
+
+
+Converting Trace Output Data
+----------------------------
+
+The trace output data is kept in a binary format which is not documented
+here. To convert it into something useful, you can use proftool.
+
+This tool must be given the U-Boot map file and the trace data received
+from running that U-Boot. It produces a text output file.
+
+Options
+ -m <map_file>
+ Specify U-Boot map file
+
+ -p <trace_file>
+ Specifiy profile/trace file
+
+Commands:
+
+- dump-ftrace
+ Write a text dump of the file in Linux ftrace format to stdout
+
+
+Viewing the Trace Data
+----------------------
+
+You can use pytimechart for this (sudo apt-get pytimechart might work on
+your Debian-style machine, and use your favourite search engine to obtain
+documentation). It expects the file to have a .txt extension. The program
+has terse user interface but is very convenient for viewing U-Boot
+profile information.
+
+
+Workflow Suggestions
+--------------------
+
+The following suggestions may be helpful if you are trying to reduce boot
+time:
+
+1. Enable CONFIG_BOOTSTAGE and CONFIG_BOOTSTAGE_REPORT. This should get
+you are helpful overall snapshot of the boot time.
+
+2. Build U-Boot with tracing and run it. Note the difference in boot time
+(it is common for tracing to add 10% to the time)
+
+3. Collect the trace information as descibed above. Use this to find where
+all the time is being spent.
+
+4. Take a look at that code and see if you can optimise it. Perhaps it is
+possible to speed up the initialisation of a device, or remove an unused
+feature.
+
+5. Rebuild, run and collect again. Compare your results.
+
+6. Keep going until you run out of steam, or your boot is fast enough.
+
+
+Configuring Trace
+-----------------
+
+There are a few parameters in the code that you may want to consider.
+There is a function call depth limit (set to 15 by default). When the
+stack depth goes above this then no tracing information is recorded.
+The maximum depth reached is recorded and displayed by the 'trace stats'
+command.
+
+
+Future Work
+-----------
+
+Tracing could be a little tidier in some areas, for example providing
+run-time configuration options for trace.
+
+Some other features that might be useful:
+
+- Trace filter to select which functions are recorded
+- Sample-based profiling using a timer interrupt
+- Better control over trace depth
+- Compression of trace information
+
+
+Simon Glass <sjg@chromium.org>
+April 2013
diff --git a/marvell/uboot/doc/README.ubi b/marvell/uboot/doc/README.ubi
new file mode 100644
index 0000000..9efab6c
--- /dev/null
+++ b/marvell/uboot/doc/README.ubi
@@ -0,0 +1,225 @@
+-------------------
+UBI usage in U-Boot
+-------------------
+
+UBI support in U-Boot is broken down into five separate commands.
+The first is the ubi command, which has six subcommands:
+
+=> help ubi
+ubi - ubi commands
+
+Usage:
+ubi part [part] [offset]
+ - Show or set current partition (with optional VID header offset)
+ubi info [l[ayout]] - Display volume and ubi layout information
+ubi create[vol] volume [size] [type] - create volume name with size
+ubi write[vol] address volume size - Write volume from address with size
+ubi write.part address volume size [fullsize]
+ - Write part of a volume from address
+ubi read[vol] address volume [size] - Read volume to address with size
+ubi remove[vol] volume - Remove volume
+[Legends]
+ volume: character name
+ size: specified in bytes
+ type: s[tatic] or d[ynamic] (default=dynamic)
+
+
+The first command that is needed to be issues is "ubi part" to connect
+one mtd partition to the UBI subsystem. This command will either create
+a new UBI device on the requested MTD partition. Or it will attach a
+previously created UBI device. The other UBI commands will only work
+when such a UBI device is attached (via "ubi part"). Here an example:
+
+=> mtdparts
+
+device nor0 <1fc000000.nor_flash>, # parts = 6
+ #: name size offset mask_flags
+ 0: kernel 0x00200000 0x00000000 0
+ 1: dtb 0x00040000 0x00200000 0
+ 2: root 0x00200000 0x00240000 0
+ 3: user 0x01ac0000 0x00440000 0
+ 4: env 0x00080000 0x01f00000 0
+ 5: u-boot 0x00080000 0x01f80000 0
+
+active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000
+
+defaults:
+mtdids : nor0=1fc000000.nor_flash
+mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot)
+
+=> ubi part root
+Creating 1 MTD partitions on "nor0":
+0x000000240000-0x000000440000 : "mtd=2"
+UBI: attaching mtd1 to ubi0
+UBI: physical eraseblock size: 262144 bytes (256 KiB)
+UBI: logical eraseblock size: 262016 bytes
+UBI: smallest flash I/O unit: 1
+UBI: VID header offset: 64 (aligned 64)
+UBI: data offset: 128
+UBI: attached mtd1 to ubi0
+UBI: MTD device name: "mtd=2"
+UBI: MTD device size: 2 MiB
+UBI: number of good PEBs: 8
+UBI: number of bad PEBs: 0
+UBI: max. allowed volumes: 128
+UBI: wear-leveling threshold: 4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes: 1
+UBI: available PEBs: 0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 2/1
+
+
+Now that the UBI device is attached, this device can be modified
+using the following commands:
+
+ubi info Display volume and ubi layout information
+ubi createvol Create UBI volume on UBI device
+ubi removevol Remove UBI volume from UBI device
+ubi read Read data from UBI volume to memory
+ubi write Write data from memory to UBI volume
+ubi write.part Write data from memory to UBI volume, in parts
+
+
+Here a few examples on the usage:
+
+=> ubi create testvol
+Creating dynamic volume testvol of size 1048064
+
+=> ubi info l
+UBI: volume information dump:
+UBI: vol_id 0
+UBI: reserved_pebs 4
+UBI: alignment 1
+UBI: data_pad 0
+UBI: vol_type 3
+UBI: name_len 7
+UBI: usable_leb_size 262016
+UBI: used_ebs 4
+UBI: used_bytes 1048064
+UBI: last_eb_bytes 262016
+UBI: corrupted 0
+UBI: upd_marker 0
+UBI: name testvol
+
+UBI: volume information dump:
+UBI: vol_id 2147479551
+UBI: reserved_pebs 2
+UBI: alignment 1
+UBI: data_pad 0
+UBI: vol_type 3
+UBI: name_len 13
+UBI: usable_leb_size 262016
+UBI: used_ebs 2
+UBI: used_bytes 524032
+UBI: last_eb_bytes 2
+UBI: corrupted 0
+UBI: upd_marker 0
+UBI: name layout volume
+
+=> ubi info
+UBI: MTD device name: "mtd=2"
+UBI: MTD device size: 2 MiB
+UBI: physical eraseblock size: 262144 bytes (256 KiB)
+UBI: logical eraseblock size: 262016 bytes
+UBI: number of good PEBs: 8
+UBI: number of bad PEBs: 0
+UBI: smallest flash I/O unit: 1
+UBI: VID header offset: 64 (aligned 64)
+UBI: data offset: 128
+UBI: max. allowed volumes: 128
+UBI: wear-leveling threshold: 4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes: 1
+UBI: available PEBs: 0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 4/1
+
+=> ubi write 800000 testvol 80000
+Volume "testvol" found at volume id 0
+
+=> ubi read 900000 testvol 80000
+Volume testvol found at volume id 0
+read 524288 bytes from volume 0 to 900000(buf address)
+
+=> cmp.b 800000 900000 80000
+Total of 524288 bytes were the same
+
+
+Next, the ubifsmount command allows you to access filesystems on the
+UBI partition which has been attached with the ubi part command:
+
+=> help ubifsmount
+ubifsmount - mount UBIFS volume
+
+Usage:
+ubifsmount <volume-name>
+ - mount 'volume-name' volume
+
+For example:
+
+=> ubifsmount ubi0:recovery
+UBIFS: mounted UBI device 0, volume 0, name "recovery"
+UBIFS: mounted read-only
+UBIFS: file system size: 46473216 bytes (45384 KiB, 44 MiB, 366 LEBs)
+UBIFS: journal size: 6348800 bytes (6200 KiB, 6 MiB, 50 LEBs)
+UBIFS: media format: w4/r0 (latest is w4/r0)
+UBIFS: default compressor: LZO
+UBIFS: reserved for root: 0 bytes (0 KiB)
+
+Note that unlike Linux, U-Boot can only have one active UBI partition
+at a time, which can be referred to as ubi0, and must be supplied along
+with the name of the filesystem you are mounting.
+
+
+Once a UBI filesystem has been mounted, the ubifsls command allows you
+to list the contents of a directory in the filesystem:
+
+
+=> help ubifsls
+ubifsls - list files in a directory
+
+Usage:
+ubifsls [directory]
+ - list files in a 'directory' (default '/')
+
+For example:
+
+=> ubifsls
+ 17442 Thu Jan 01 02:57:38 1970 imx28-evk.dtb
+ 2998146 Thu Jan 01 02:57:43 1970 zImage
+
+
+And the ubifsload command allows you to load a file from a UBI
+filesystem:
+
+
+=> help ubifsload
+ubifsload - load file from an UBIFS filesystem
+
+Usage:
+ubifsload <addr> <filename> [bytes]
+ - load file 'filename' to address 'addr'
+
+For example:
+
+=> ubifsload ${loadaddr} zImage
+Loading file 'zImage' to addr 0x42000000 with size 2998146 (0x002dbf82)...
+Done
+
+
+Finally, you can unmount the UBI filesystem with the ubifsumount
+command:
+
+=> help ubifsumount
+ubifsumount - unmount UBIFS volume
+
+Usage:
+ubifsumount - unmount current volume
+
+For example:
+
+=> ubifsumount
+Unmounting UBIFS volume recovery!
diff --git a/marvell/uboot/doc/README.ublimage b/marvell/uboot/doc/README.ublimage
new file mode 100644
index 0000000..ab25b26
--- /dev/null
+++ b/marvell/uboot/doc/README.ublimage
@@ -0,0 +1,141 @@
+---------------------------------------------
+UBL image Boot Image generation using mkimage
+---------------------------------------------
+
+This document describes how to set up an U-Boot image that can be directly
+booted by a DaVinci processor via NAND boot mode, using an UBL header,
+but without need for UBL.
+
+For more details see section 11.2 "ARM ROM Boot Modes" of
+http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf
+
+Command syntax:
+--------------
+./tools/mkimage -l <u-boot_file>
+ to list the UBL image file details
+
+./tools/mkimage -T ublimage \
+ -n <board specific configuration file> \
+ -d <u-boot binary> <output image file>
+
+For example, for the davinci dm365evm board:
+./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg \
+ -T ublimage \
+ -d u-boot-nand.bin u-boot.ubl
+
+You can generate the image directly when you compile u-boot with:
+
+$ make u-boot.ubl
+
+The output image can be flashed into the NAND.
+
+Please check the DaVinci documentation for further details.
+
+Board specific configuration file specifications:
+-------------------------------------------------
+1. This file must present in the $(BOARDDIR) and the name should be
+ ublimage.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 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
+ -------------- -----------
+ MODE UBL special mode, on of:
+ safe
+ Example:
+ MODE safe
+
+ ENTRY Entry point address for the user
+ bootloader (absolute address) = TEXT_BASE
+ nand_spl loader.
+ Example:
+ ENTRY 0x00000020
+
+ PAGES Number of pages (size of user bootloader
+ in number of pages)
+ Example:
+ PAGES 27
+
+ START_BLOCK Block number where user bootloader is present
+ Example:
+ START_BLOCK 5
+
+ START_PAGE Page number where user bootloader is present
+ (for RBL always 0)
+ Example:
+ START_PAGE 0
+
+------------------------------------------------
+
+Structure of the u-boot.ubl binary:
+
+compile steps:
+
+1) nand_spl code compile, with pad_to = (TEXT_BASE +
+ (CONFIG_SYS_NROF_PAGES_NAND_SPL * pagesize))
+ Example: cam_enc_4xx pad_to = 0x20 + (6 * 0x800) = 0x3020 = 12320
+ -> u-boot-spl-16k.bin
+
+ !! TEXT_BASE = 0x20, as the RBL starts at 0x20
+
+2) compile u-boot.bin ("normal" u-boot)
+ -> u-boot.bin
+
+3) create u-boot-nand.bin = u-boot-spl-16k.bin + u-boot.bin
+
+4) create u-boot.ubl, size = 1 page size NAND
+ create UBL header and paste it before u-boot.bin
+
+This steps are done automagically if you do a "make all"
+
+-> You get an u-boot.ubl binary, which you can flash
+ into your NAND.
+
+Structure of this binary (Example for the cam_enc_4xx board with a NAND
+page size = 0x800):
+
+offset : 0x00000 | 0x800 | 0x3800
+content: UBL | nand_spl | u-boot code
+ Header | code |
+
+The NAND layout looks for example like this:
+
+(Example for the cam_enc_4xx board with a NAND page size = 0x800, block
+size = 0x20000 and CONFIG_SYS_NROF_UBL_HEADER 5):
+
+offset : 0x80000 | 0xa0000 | 0xa3000
+content: UBL | nand_spl | u-boot code
+ Header | code |
+ ^ ^
+ ^ 0xa0000 = CONFIG_SYS_NROF_UBL_HEADER * 0x20000
+ ^
+ 0x80000 = Block 4 * 0x20000
+
+If the cpu starts in NAND boot mode, it checks the UBL descriptor
+starting with block 1 (page 0). When a valid UBL signature is found,
+the corresponding block number (from 1 to 24) is written to the last 32
+bits of ARM internal memory (0x7ffc-0x8000). This feature is provided
+as a basic debug mechanism. If not found, it continues with block 2
+... last possible block is 24
+
+If a valid UBL descriptor is found, the UBL descriptor is read and
+processed. The descriptor gives the information required for loading
+and control transfer to the nand_spl code. The nand_spl code is then
+read and processed.
+
+Once the user-specified start-up conditions are set, the RBL copies the
+nand_spl into ARM internal RAM, starting at address 0x0000: 0020.
+ ^^^^
+
+The nand_spl code itself now does necessary intializations, and at least,
+copies the u-boot code from NAND into RAM, and jumps to it ...
+
+------------------------------------------------
+Author: Heiko Schocher <hs@denx.de>
diff --git a/marvell/uboot/doc/README.update b/marvell/uboot/doc/README.update
new file mode 100644
index 0000000..a7f4d9e
--- /dev/null
+++ b/marvell/uboot/doc/README.update
@@ -0,0 +1,95 @@
+Automatic software update from a TFTP server
+============================================
+
+Overview
+--------
+
+This feature allows to automatically store software updates present on a TFTP
+server in NOR Flash. In more detail: a TFTP transfer of a file given in
+environment variable 'updatefile' from server 'serverip' is attempted during
+boot. The update file should be a FIT file, and can contain one or more
+updates. Each update in the update file has an address in NOR Flash where it
+should be placed, updates are also protected with a SHA-1 checksum. If the
+TFTP transfer is successful, the hash of each update is verified, and if the
+verification is positive, the update is stored in Flash.
+
+The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
+
+#define CONFIG_UPDATE_TFTP 1
+
+
+Note that when enabling auto-update, Flash support must be turned on. Also,
+one must enable FIT and LIBFDT support:
+
+#define CONFIG_FIT 1
+#define CONFIG_OF_LIBFDT 1
+
+The auto-update feature uses the following configuration knobs:
+
+- CONFIG_UPDATE_LOAD_ADDR
+
+ Normally, TFTP transfer of the update file is done to the address specified
+ in environment variable 'loadaddr'. If this variable is not present, the
+ transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
+ by default).
+
+- CONFIG_UPDATE_TFTP_CNT_MAX
+ CONFIG_UPDATE_TFTP_MSEC_MAX
+
+ These knobs control the timeouts during initial connection to the TFTP
+ server. Since a transfer is attempted during each boot, it is undesirable to
+ have a long delay when a TFTP server is not present.
+ CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
+ the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
+ gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
+ be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
+ positive and is 100 by default.
+
+Since the update file is in FIT format, it is created from an *.its file using
+the mkimage tool. dtc tool with support for binary includes, e.g. in version
+1.2.0 or later, must also be available on the system where the update file is
+to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
+images.
+
+This mechanism can be also triggered by the commmand "fitupd".
+If an optional, non-zero address is provided as argument, the TFTP transfer
+is skipped and the image at this address is used.
+The fitupd command is enabled by CONFIG_CMD_FITUPD.
+
+
+Example .its files
+------------------
+
+- doc/uImage.FIT/update_uboot.its
+
+ A simple example that can be used to create an update file for automatically
+ replacing U-Boot image on a system.
+
+ Assuming that an U-Boot image u-boot.bin is present in the current working
+ directory, and that the address given in the 'load' property in the
+ 'update_uboot.its' file is where the U-Boot is stored in Flash, the
+ following command will create the actual update file 'update_uboot.itb':
+
+ mkimage -f update_uboot.its update_uboot.itb
+
+ Place 'update_uboot.itb' on a TFTP server, for example as
+ '/tftpboot/update_uboot.itb', and set the 'updatefile' variable
+ appropriately, for example in the U-Boot prompt:
+
+ setenv updatefile /tftpboot/update_uboot.itb
+ saveenv
+
+ Now, when the system boots up and the update TFTP server specified in the
+ 'serverip' environment variable is accessible, the new U-Boot image will be
+ automatically stored in Flash.
+
+ NOTE: do make sure that the 'u-boot.bin' image used to create the update
+ file is a good, working image. Also make sure that the address in Flash
+ where the update will be placed is correct. Making mistake here and
+ attempting the auto-update can render the system unusable.
+
+- doc/uImage.FIT/update3.its
+
+ An example containing three updates. It can be used to update Linux kernel,
+ ramdisk and FDT blob stored in Flash. The procedure for preparing the update
+ file is similar to the example above.
diff --git a/marvell/uboot/doc/README.usb b/marvell/uboot/doc/README.usb
new file mode 100644
index 0000000..65fb288
--- /dev/null
+++ b/marvell/uboot/doc/README.usb
@@ -0,0 +1,219 @@
+/*
+ * (C) Copyright 2001
+ * Denis Peter, MPL AG Switzerland
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+USB Support for PIP405 and MIP405 (UHCI)
+========================================
+
+The USB support is implemented on the base of the UHCI Host
+controller.
+
+Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
+flash sticks and USB network adaptors.
+Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
+
+How it works:
+-------------
+
+The USB (at least the USB UHCI) needs a frame list (4k), transfer
+descripor and queue headers which are all located in the main memory.
+The UHCI allocates every milisecond the PCI bus and reads the current
+frame pointer. This may cause to crash the OS during boot. So the USB
+_MUST_ be stopped during OS boot. This is the reason, why the USB is
+NOT automatically started during start-up. If someone needs the USB
+he has to start it and should therefore be aware that he had to stop
+it before booting the OS.
+
+For USB keyboards this can be done by a script which is automatically
+started after the U-Boot is up and running. To boot an OS with a an
+USB keyboard another script is necessary, which first disables the
+USB and then executes the boot command. If the boot command fails,
+the script can reenable the USB kbd.
+
+Common USB Commands:
+- usb start:
+- usb reset: (re)starts the USB. All USB devices will be
+ initialized and a device tree is build for them.
+- usb tree: shows all USB devices in a tree like display
+- usb info [dev]: shows all USB infos of the device dev, or of all
+ the devices
+- usb stop [f]: stops the USB. If f==1 the USB will also stop if
+ an USB keyboard is assigned as stdin. The stdin
+ is then switched to serial input.
+Storage USB Commands:
+- usb scan: scans the USB for storage devices.The USB must be
+ running for this command (usb start)
+- usb device [dev]: show or set current USB storage device
+- usb part [dev]: print partition table of one or all USB storage
+ devices
+- usb read addr blk# cnt:
+ read `cnt' blocks starting at block `blk#'to
+ memory address `addr'
+- usbboot addr dev:part:
+ boot from USB device
+
+Config Switches:
+----------------
+CONFIG_CMD_USB enables basic USB support and the usb command
+CONFIG_USB_UHCI defines the lowlevel part.A lowlevel part must be defined
+ if using CONFIG_CMD_USB
+CONFIG_USB_KEYBOARD enables the USB Keyboard
+CONFIG_USB_STORAGE enables the USB storage devices
+CONFIG_USB_HOST_ETHER enables USB ethernet adapter support
+
+
+USB Host Networking
+===================
+
+If you have a supported USB Ethernet adapter you can use it in U-Boot
+to obtain an IP address and load a kernel from a network server.
+
+Note: USB Host Networking is not the same as making your board act as a USB
+client. In that case your board is pretending to be an Ethernet adapter
+and will appear as a network interface to an attached computer. In that
+case the connection is via a USB cable with the computer acting as the host.
+
+With USB Host Networking, your board is the USB host. It controls the
+Ethernet adapter to which it is directly connected and the connection to
+the outside world is your adapter's Ethernet cable. Your board becomes an
+independent network device, able to connect and perform network operations
+independently of your computer.
+
+
+Device support
+--------------
+
+Currently supported devices are listed in the drivers according to
+their vendor and product IDs. You can check your device by connecting it
+to a Linux machine and typing 'lsusb'. The drivers are in
+drivers/usb/eth.
+
+For example this lsusb output line shows a device with Vendor ID 0x0x95
+and product ID 0x7720:
+
+Bus 002 Device 010: ID 0b95:7720 ASIX Electronics Corp. AX88772
+
+If you look at drivers/usb/eth/asix.c you will see this line within the
+supported device list, so we know this adapter is supported.
+
+ { 0x0b95, 0x7720 }, /* Trendnet TU2-ET100 V3.0R */
+
+If your adapter is not listed there is a still a chance that it will
+work. Try looking up the manufacturer of the chip inside your adapter.
+or take the adapter apart and look for chip markings. Then add a line
+for your vendor/product ID into the table of the appropriate driver,
+build U-Boot and see if it works. If not then there might be differences
+between the chip in your adapter and the driver. You could try to get a
+datasheet for your device and add support for it to U-Boot. This is not
+particularly difficult - you only need to provide support for four basic
+functions: init, halt, send and recv.
+
+
+Enabling USB Host Networking
+----------------------------
+
+The normal U-Boot commands are used with USB networking, but you must
+start USB first. For example:
+
+usb start
+setenv bootfile /tftpboot/uImage
+bootp
+
+
+To enable USB Host Ethernet in U-Boot, your platform must of course
+support USB with CONFIG_CMD_USB enabled and working. You will need to
+add some config settings to your board header file:
+
+#define CONFIG_USB_HOST_ETHER /* Enable USB Ethernet adapters */
+#define CONFIG_USB_ETHER_ASIX /* Asix, or whatever driver(s) you want */
+
+As with built-in networking, you will also want to enable some network
+commands, for example:
+
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+
+and some bootp options, which tell your board to obtain its subnet,
+gateway IP, host name and boot path from the bootp/dhcp server. These
+settings should start you off:
+
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_BOOTPATH
+
+You can also set the default IP address of your board and the server
+as well as the default file to load when a 'bootp' command is issued.
+All of these can be obtained from the bootp server if not set.
+
+#define CONFIG_IPADDR 10.0.0.2 (replace with your value)
+#define CONFIG_SERVERIP 10.0.0.1 (replace with your value)
+#define CONFIG_BOOTFILE "uImage"
+
+
+The 'usb start' command should identify the adapter something like this:
+
+CrOS> usb start
+(Re)start USB...
+USB EHCI 1.00
+scanning bus for devices... 3 USB Device(s) found
+ scanning bus for storage devices... 0 Storage Device(s) found
+ scanning bus for ethernet devices... 1 Ethernet Device(s) found
+CrOS> print ethact
+ethact=asx0
+
+You can see that it found an ethernet device and we can print out the
+device name (asx0 in this case).
+
+Then 'bootp' or 'dhcp' should use it to obtain an IP address from DHCP,
+perhaps something like this:
+
+CrOS> bootp
+Waiting for Ethernet connection... done.
+BOOTP broadcast 1
+BOOTP broadcast 2
+DHCP client bound to address 172.22.73.81
+Using asx0 device
+TFTP from server 172.22.72.144; our IP address is 172.22.73.81
+Filename '/tftpboot/uImage-sjg-seaboard-261347'.
+Load address: 0x40c000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ ################################################
+done
+Bytes transferred = 3557464 (364858 hex)
+CrOS>
+
+
+Another way of doing this is to issue a tftp command, which will cause the
+bootp to happen automatically.
+
+
+MAC Addresses
+-------------
+
+Most Ethernet dongles have a built-in MAC address which is unique in the
+world. This is important so that devices on the network can be
+distinguised from each other. MAC address conflicts are evil and
+generally result in strange and eratic behaviour.
+
+Some boards have USB Ethernet chips on-board, and these sometimes do not
+have an assigned MAC address. In this case it is up to you to assign
+one which is unique. You should obtain a valid MAC address from a range
+assigned to you before you ship the product.
+
+Built-in Ethernet adapters support setting the MAC address by means of
+an ethaddr environment variable for each interface (ethaddr, eth1addr,
+eth2addr). There is similar support on the USB network side, using the
+names usbethaddr, usbeth1addr, etc. They are kept separate since we
+don't want a USB device taking the MAC address of a built-in device or
+vice versa.
+
+So if your USB Ethernet chip doesn't have a MAC address available then
+you must set usbethaddr to a suitable MAC address. At the time of
+writing this functionality is only supported by the SMSC driver.
diff --git a/marvell/uboot/doc/README.vf610 b/marvell/uboot/doc/README.vf610
new file mode 100644
index 0000000..38cf5cf
--- /dev/null
+++ b/marvell/uboot/doc/README.vf610
@@ -0,0 +1,10 @@
+U-Boot for Freescale Vybrid VF610
+
+This file contains information for the port of U-Boot to the Freescale Vybrid
+VF610 SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the
+ 32 lsbs in word 3.
diff --git a/marvell/uboot/doc/README.video b/marvell/uboot/doc/README.video
new file mode 100644
index 0000000..f09d5f9
--- /dev/null
+++ b/marvell/uboot/doc/README.video
@@ -0,0 +1,33 @@
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+U-Boot MPC8xx video controller driver
+======================================
+
+The driver has been tested with the following configurations:
+
+- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
+- GENIETV with AD7177 on a PAL TV (YCbYCr) - arsenio@tin.it
+
+
+"video-mode" environment variable
+===============================
+
+The 'video-mode' environment variable can be used to enable and configure
+some video drivers. The format matches the video= command-line option used
+for Linux:
+
+ video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string>
+
+ <driver> The video driver name, ignored by U-Boot
+ <xres> The X resolution (in pixels) to use.
+ <yres> The Y resolution (in pixels) to use.
+ <depth> The color depth (in bits) to use.
+ <freq> The frequency (in Hz) to use.
+ <options> A comma-separated list of device-specific options
+
+Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi
diff --git a/marvell/uboot/doc/README.vxworks b/marvell/uboot/doc/README.vxworks
new file mode 100644
index 0000000..4cb302e
--- /dev/null
+++ b/marvell/uboot/doc/README.vxworks
@@ -0,0 +1,19 @@
+From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware
+decription mechansim (for PowerPC and ARM), thus requiring boot interface changes.
+This section will describe the new interface.
+
+For PowerPC, the calling convention of the new VxWorks entry point conforms to the ePAPR standard,
+which is shown below (see ePAPR for more details):
+
+ void (*kernel_entry)(fdt_addr,
+ 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
+
+For ARM, the calling convention is show below:
+
+ void (*kernel_entry)(void *fdt_addr)
+
+When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below:
+
+ bootm <kernel image address> - <device tree address>
+
+The do_bootvx command still works as it was for older VxWorks kernels.
diff --git a/marvell/uboot/doc/README.watchdog b/marvell/uboot/doc/README.watchdog
new file mode 100644
index 0000000..59f306b
--- /dev/null
+++ b/marvell/uboot/doc/README.watchdog
@@ -0,0 +1,35 @@
+Watchdog driver general info
+
+CONFIG_HW_WATCHDOG
+ This enables hw_watchdog_reset to be called during various loops,
+ including waiting for a character on a serial port. But it
+ does not also call hw_watchdog_init. Boards which want this
+ enabled must call this function in their board file. This split
+ is useful because some rom's enable the watchdog when downloading
+ new code, so it must be serviced, but the board would rather it
+ was off. And, it cannot always be turned off once on.
+
+CONFIG_WATCHDOG_TIMEOUT_MSECS
+ Can be used to change the timeout for i.mx31/35/5x/6x.
+ If not given, will default to maximum timeout. This would
+ be 128000 msec for i.mx31/35/5x/6x.
+
+CONFIG_AT91SAM9_WATCHDOG
+ Available for AT91SAM9 to service the watchdog.
+
+CONFIG_FTWDT010_WATCHDOG
+ Available for FTWDT010 to service the watchdog.
+
+CONFIG_FTWDT010_HW_TIMEOUT
+ Can be used to change the timeout for FTWDT010.
+
+CONFIG_IMX_WATCHDOG
+ Available for i.mx31/35/5x/6x to service the watchdog. This is not
+ automatically set because some boards (vision2) still need to define
+ their own hw_watchdog_reset routine.
+
+CONFIG_XILINX_TB_WATCHDOG
+ Available for Xilinx Axi platforms to service timebase watchdog timer.
+
+CONFIG_BFIN_WATCHDOG
+ Available for bf5xx and bf6xx to service the watchdog.
diff --git a/marvell/uboot/doc/README.zfs b/marvell/uboot/doc/README.zfs
new file mode 100644
index 0000000..7f237c4
--- /dev/null
+++ b/marvell/uboot/doc/README.zfs
@@ -0,0 +1,29 @@
+This patch series adds support for ZFS listing and load to u-boot.
+
+To Enable zfs ls and load commands, modify the board specific config file with
+#define CONFIG_CMD_ZFS
+
+Steps to test:
+
+1. After applying the patch, zfs specific commands can be seen
+ in the boot loader prompt using
+ UBOOT #help
+
+ zfsload- load binary file from a ZFS file system
+ zfsls - list files in a directory (default /)
+
+2. To list the files in zfs pool, device or partition, execute
+ zfsls <interface> <dev[:part]> [POOL/@/dir/file]
+ For example:
+ UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/
+
+3. To read and load a file from an ZFS formatted partition to RAM, execute
+ zfsload <interface> <dev[:part]> [addr] [filename] [bytes]
+ For example:
+ UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage
+
+References :
+ -- ZFS GRUB sources from Solaris GRUB-0.97
+ -- GRUB Bazaar repository
+
+Jorgen Lundman <lundman at lundman.net> 2012.
diff --git a/marvell/uboot/doc/README.zynq b/marvell/uboot/doc/README.zynq
new file mode 100644
index 0000000..043c970
--- /dev/null
+++ b/marvell/uboot/doc/README.zynq
@@ -0,0 +1,94 @@
+#
+# Xilinx ZYNQ U-Boot
+#
+# (C) Copyright 2013 Xilinx, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+1. About this
+
+This document describes the information about Xilinx Zynq U-Boot -
+like supported boards, ML status and TODO list.
+
+2. Zynq boards
+
+Xilinx Zynq-7000 All Programmable SoCs enable extensive system level
+differentiation, integration, and flexibility through hardware, software,
+and I/O programmability.
+
+* zc70x
+ - zc702 (single qspi, gem0, mmc) [1]
+ - zc706 (dual parallel qspi, gem0, mmc) [2]
+* zed (single qspi, gem0, mmc) [3]
+* microzed (single qspi, gem0, mmc) [4]
+* zc770
+ - zc770-xm010 (single qspi, gem0, mmc)
+ - zc770-xm011 (8 or 16 bit nand)
+ - zc770-xm012 (nor)
+ - zc770-xm013 (dual parallel qspi, gem1)
+
+3. Building
+
+ # Configure for zc70x board
+ $ make zynq_zc70x_config
+ Configuring for zynq_zc70x board...
+
+ # Building default dts for zc702 board
+ $ make
+
+ # Building specified dts for zc706 board
+ $ make DEVICE_TREE=zynq-zc706
+
+4. Bootmode
+
+Zynq has a facility to read the bootmode from the slcr bootmode register
+once user is setting through jumpers on the board - see page no:1546 on [5]
+
+All possible bootmode values are defined in Table 6-2:Boot_Mode MIO Pins
+on [5].
+
+board_late_init() will read the bootmode values using slcr bootmode register
+at runtime and assign the modeboot variable to specific bootmode string which
+is intern used in autoboot.
+
+SLCR bootmode register Bit[3:0] values
+#define ZYNQ_BM_NOR 0x02
+#define ZYNQ_BM_SD 0x05
+#define ZYNQ_BM_JTAG 0x0
+
+"modeboot" variable can assign any of "norboot", "sdboot" or "jtagboot"
+bootmode strings at runtime.
+
+5. Mainline status
+
+- Added basic board configurations support.
+- Added zynq u-boot bsp code - arch/arm/cpu/armv7/zynq
+- Added zynq boards named - zc70x, zed, microzed, zc770_xm010, zc770_xm012, zc770_xm013
+- Added zynq drivers:
+ serial - drivers/serial/serial_zynq.c
+ net - drivers/net/zynq_gem.c
+ mmc - drivers/mmc/zynq_sdhci.c
+ mmc - drivers/mmc/zynq_sdhci.c
+ spi- drivers/spi/zynq_spi.c
+ i2c - drivers/i2c/zynq_i2c.c
+- Done proper cleanups on board configurations
+- Added basic FDT support for zynq boards
+- d-cache support for zynq_gem.c
+
+6. TODO
+
+- Add zynq boards support - zc770_xm011
+- Add zynq qspi controller driver
+- Add zynq nand controller driver
+- Add FDT support on individual drivers
+
+[1] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm
+[2] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm
+[3] http://zedboard.org/product/zedboard
+[4] http://zedboard.org/product/microzed
+[5] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
+
+--
+Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
+Sun Dec 15 14:52:41 IST 2013
diff --git a/marvell/uboot/doc/SPI/README.dual-flash b/marvell/uboot/doc/SPI/README.dual-flash
new file mode 100644
index 0000000..6c88d65
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.dual-flash
@@ -0,0 +1,92 @@
+SPI/QSPI Dual flash connection modes:
+=====================================
+
+This describes how SPI/QSPI flash memories are connected to a given
+controller in a single chip select line.
+
+Current spi_flash framework supports, single flash memory connected
+to a given controller with single chip select line, but there are some
+hw logics(ex: xilinx zynq qspi) that describes two/dual memories are
+connected with a single chip select line from a controller.
+
+"dual_flash" from include/spi.h describes these types of connection mode
+
+Possible connections:
+--------------------
+SF_SINGLE_FLASH:
+ - single spi flash memory connected with single chip select line.
+
+ +------------+ CS +---------------+
+ | |----------------------->| |
+ | Controller | I0[3:0] | Flash memory |
+ | SPI/QSPI |<======================>| (SPI/QSPI) |
+ | | CLK | |
+ | |----------------------->| |
+ +------------+ +---------------+
+
+SF_DUAL_STACKED_FLASH:
+ - dual spi/qspi flash memories are connected with a single chipselect
+ line and these two memories are operating stacked fasion with shared buses.
+ - xilinx zynq qspi controller has implemented this feature [1]
+
+ +------------+ CS +---------------+
+ | |---------------------->| |
+ | | I0[3:0] | Upper Flash |
+ | | +=========>| memory |
+ | | | CLK | (SPI/QSPI) |
+ | | | +---->| |
+ | Controller | CS | | +---------------+
+ | SPI/QSPI |------------|----|---->| |
+ | | I0[3:0] | | | Lower Flash |
+ | |<===========+====|====>| memory |
+ | | CLK | | (SPI/QSPI) |
+ | |-----------------+---->| |
+ +------------+ +---------------+
+
+ - two memory flash devices should has same hw part attributes (like size,
+ vendor..etc)
+ - Configurations:
+ on LQSPI_CFG register, Enable TWO_MEM[BIT:30] on LQSPI_CFG
+ Enable U_PAGE[BIT:28] if U_PAGE flag set - upper memory
+ Disable U_PAGE[BIT:28] if U_PAGE flag unset - lower memory
+ - Operation:
+ accessing memories serially like one after another.
+ by default, if U_PAGE is unset lower memory should accessible,
+ once user wants to access upper memory need to set U_PAGE.
+
+SPI_FLASH_CONN_DUALPARALLEL:
+ - dual spi/qspi flash memories are connected with a single chipselect
+ line and these two memories are operating parallel with separate buses.
+ - xilinx zynq qspi controller has implemented this feature [1]
+
+ +-------------+ CS +---------------+
+ | |---------------------->| |
+ | | I0[3:0] | Upper Flash |
+ | |<=====================>| memory |
+ | | CLK | (SPI/QSPI) |
+ | |---------------------->| |
+ | Controller | CS +---------------+
+ | SPI/QSPI |---------------------->| |
+ | | I0[3:0] | Lower Flash |
+ | |<=====================>| memory |
+ | | CLK | (SPI/QSPI) |
+ | |---------------------->| |
+ +-------------+ +---------------+
+
+ - two memory flash devices should has same hw part attributes (like size,
+ vendor..etc)
+ - Configurations:
+ Need to enable SEP_BUS[BIT:29],TWO_MEM[BIT:30] on LQSPI_CFG register.
+ - Operation:
+ Even bits, i.e. bit 0, 2, 4 ., of a data word is located in the lower memory
+ and odd bits, i.e. bit 1, 3, 5, ., of a data word is located in the upper memory.
+
+Note: Technically there is only one CS line from the controller, but
+zynq qspi controller has an internal hw logic to enable additional CS
+when controller is configured for dual memories.
+
+[1] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
+
+--
+Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
+05-01-2014.
diff --git a/marvell/uboot/doc/SPI/README.ftssp010_spi_test b/marvell/uboot/doc/SPI/README.ftssp010_spi_test
new file mode 100644
index 0000000..1d86f36
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ftssp010_spi_test
@@ -0,0 +1,41 @@
+SPI Flash test on Faraday A369 EVB:
+==================================
+
+U-Boot 2014.01-rc2-g3444b6f (Dec 20 2013 - 10:58:40)
+
+CPU: FA626TE 528 MHz
+AHB: 132 MHz
+APB: 66 MHz
+I2C: ready
+DRAM: 256 MiB
+MMU: on
+NAND: 512 MiB
+MMC: ftsdc010: 0
+*** Warning - bad CRC, using default environment
+
+In: serial
+Out: serial
+Err: serial
+Net: FTGMAC100#0
+Hit any key to stop autoboot: 0
+=> sf probe 0:0
+SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB, total 2 MiB
+=> sf read 0x10800000 0 0x400
+SF: 1024 bytes @ 0x0 Read: OK
+=> md 0x10800000
+10800000: ea000013 e59ff014 e59ff014 e59ff014 ................
+10800010: e59ff014 e59ff014 e59ff014 e59ff014 ................
+10800020: 1ff7b0c0 1ff7b120 1ff7b180 1ff7b1e0 .... ...........
+10800030: 1ff7b240 1ff7b2a0 1ff7b300 deadbeef @...............
+10800040: 10800000 0002c1f0 0007409c 00032048 .........@..H ..
+10800050: 1fd6af40 e10f0000 e3c0001f e38000d3 @...............
+10800060: e129f000 eb000001 eb000223 e12fff1e ..).....#...../.
+10800070: e3a00000 ee070f1e ee080f17 ee070f15 ................
+10800080: ee070f9a ee110f10 e3c00c03 e3c00087 ................
+10800090: e3c00a02 e3800002 e3800a01 ee010f10 ................
+108000a0: e1a0c00e eb007a68 e1a0e00c e1a0f00e ....hz..........
+108000b0: e1a00000 e1a00000 e1a00000 e1a00000 ................
+108000c0: e51fd078 e58de000 e14fe000 e58de004 x.........O.....
+108000d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
+108000e0: e24dd048 e88d1fff e51f20a0 e892000c H.M...... ......
+108000f0: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
diff --git a/marvell/uboot/doc/SPI/README.sandbox-spi b/marvell/uboot/doc/SPI/README.sandbox-spi
new file mode 100644
index 0000000..bb73eaf
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.sandbox-spi
@@ -0,0 +1,64 @@
+Sandbox SPI/SPI Flash Implementation
+====================================
+
+U-Boot supports SPI and SPI flash emuation in sandbox. This must be enabled
+using the --spi_sf paramter when starting U-Boot.
+
+For example:
+
+$ make O=sandbox sandbox_config
+$ make O=sandbox
+$ ./sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin
+
+The four parameters to spi_sf are:
+
+ SPI bus number (typically 0)
+ SPI chip select number (typically 0)
+ SPI chip to emulate
+ File containing emulated data
+
+Supported chips are W25Q16 (2MB), W25Q32 (4MB) and W25Q128 (16MB). Once
+U-Boot it started you can use 'sf' commands as normal. For example:
+
+$ ./b/sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin \
+ -c "sf probe; sf test 0 100000; sf read 0 1000 1000; \
+ sf erase 1000 1000; sf write 0 1000 1000"
+
+
+U-Boot 2013.10-00237-gd4e0fdb (Nov 07 2013 - 20:08:15)
+
+DRAM: 128 MiB
+Using default environment
+
+In: serial
+Out: serial
+Err: serial
+SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+SPI flash test:
+0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps
+1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps
+2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps
+3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps
+Test passed
+0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps
+1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps
+2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps
+3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps
+SF: 4096 bytes @ 0x1000 Read: OK
+SF: 4096 bytes @ 0x1000 Erased: OK
+SF: 4096 bytes @ 0x1000 Written: OK
+
+
+Since the SPI bus is fully implemented as well as the SPI flash connected to
+it, you can also use low-level SPI commands to access the flash. For example
+this reads the device ID from the emulated chip:
+
+=> sspi 0 32 9f
+FFEF4018
+
+
+Simon Glass
+sjg@chromium.org
+7/11/2013
+Note that the sandbox SPI implementation was written by Mike Frysinger
+<vapier@gentoo.org>.
diff --git a/marvell/uboot/doc/SPI/README.sh_qspi_test b/marvell/uboot/doc/SPI/README.sh_qspi_test
new file mode 100644
index 0000000..8a33fec
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.sh_qspi_test
@@ -0,0 +1,38 @@
+-------------------------------------------------
+ Simple steps used to test the SH-QSPI at U-Boot
+-------------------------------------------------
+
+#0, Currently, SH-QSPI is used by lager board (Renesas ARM SoC R8A7790)
+ and koelsch board (Renesas ARM SoC R8A7791). These boot from SPI ROM
+ basically. Thus, U-Boot start, SH-QSPI will is operating normally.
+
+#1, build U-Boot and load u-boot.bin
+
+ => tftpboot 40000000 u-boot.bin
+ sh_eth Waiting for PHY auto negotiation to complete.. done
+ sh_eth: 100Base/Half
+ Using sh_eth device
+ TFTP from server 192.168.169.1; our IP address is 192.168.169.79
+ Filename 'u-boot.bin'.
+ Load address: 0x40000000
+ Loading: ############
+ 2.5 MiB/s
+ done
+ Bytes transferred = 175364 (2ad04 hex)
+
+#2, Commands to erase/write u-boot to flash device
+
+ Note: This method is description of the lager board. If you want to use the
+ other boards, please change the value according to each environment.
+
+ => sf probe 0
+ SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 64 KiB, total 64 MiB
+ => sf erase 80000 40000
+ SF: 262144 bytes @ 0x80000 Erased: OK
+ => sf write 40000000 80000 175364
+ SF: 1528676 bytes @ 0x80000 Written: OK
+ =>
+
+#3, Push reset button.
+
+ If you're written correctly and driver works properly, U-Boot starts.
diff --git a/marvell/uboot/doc/SPI/README.ti_qspi_dra_test b/marvell/uboot/doc/SPI/README.ti_qspi_dra_test
new file mode 100644
index 0000000..fe37857
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ti_qspi_dra_test
@@ -0,0 +1,48 @@
+-------------------------------------------------
+ Simple steps used to test the QSPI at U-Boot
+-------------------------------------------------
+
+For #1, build the patched U-Boot and load MLO/u-boot.img
+
+----------------------------------
+Boot from another medium like MMC
+----------------------------------
+
+U-Boot# mmc dev 0
+mmc0 is current device
+U-Boot# fatload mmc 0 0x82000000 MLO
+reading MLO
+55872 bytes read in 8 ms (6.7 MiB/s)
+U-Boot# fatload mmc 0 0x83000000 u-boot.img
+reading u-boot.img
+248600 bytes read in 19 ms (12.5 MiB/s)
+
+--------------------------------------------------
+Commands to erase/write u-boot/mlo to flash device
+--------------------------------------------------
+U-Boot# sf probe 0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
+SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
+U-Boot# sf erase 0 0x10000
+SF: 65536 bytes @ 0x0 Erased: OK
+U-Boot# sf erase 0x20000 0x10000
+SF: 65536 bytes @ 0x20000 Erased: OK
+U-Boot# sf erase 0x30000 0x10000
+SF: 65536 bytes @ 0x30000 Erased: OK
+U-Boot# sf erase 0x40000 0x10000
+SF: 65536 bytes @ 0x40000 Erased: OK
+U-Boot# sf erase 0x50000 0x10000
+SF: 65536 bytes @ 0x50000 Erased: OK
+U-Boot# sf erase 0x60000 0x10000
+SF: 65536 bytes @ 0x60000 Erased: OK
+U-Boot# sf write 82000000 0 0x10000
+SF: 65536 bytes @ 0x0 Written: OK
+U-Boot# sf write 83000000 0x20000 0x60000
+SF: 393216 bytes @ 0x20000 Written: OK
+
+For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
+on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
+then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
+find a U-Boot image header at offset 0x20000 (set in the config file)
+and proceeds to load that image using the U-Boot image payload offset/size
+from the header. It will then start U-Boot.
diff --git a/marvell/uboot/doc/SPI/README.ti_qspi_flash b/marvell/uboot/doc/SPI/README.ti_qspi_flash
new file mode 100644
index 0000000..1b86d01
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ti_qspi_flash
@@ -0,0 +1,47 @@
+QSPI U-boot support
+------------------
+
+Host processor is connected to serial flash device via qpsi
+interface. QSPI is a kind of spi module that allows single,
+dual and quad read access to external spi devices. The module
+has a memory mapped interface which provide direct interface
+for accessing data form external spi devices.
+
+The one QSPI in the device is primarily intended for fast booting
+from Quad SPI flash devices.
+
+Usecase
+-------
+
+MLO/u-boot.img will be flashed from SD/MMC to the flash device
+using serial flash erase and write commands. Then, switch settings
+will be changed to qspi boot. Then, the ROM code will read MLO
+from the predefined location in the flash, where it was flashed and
+execute it after storing it in SDRAM. Then, the MLO will read
+u-boot.img from flash and execute it from SDRAM.
+
+SPI mode
+-------
+SPI mode uses mtd spi framework for transfer and reception of data.
+Can be used in:
+1. Normal mode: use single pin for transfers
+2. Dual Mode: use two pins for transfers.
+3. Quad mode: use four pin for transfer
+
+Memory mapped read mode
+-----------------------
+In this, SPI controller is configured using configuration port and then
+controler is switched to memory mapped port for data read.
+
+Driver
+------
+drivers/qspi/ti_qspi.c
+ - Newly created file which is responsible for configuring the
+ qspi controller and also for providing the low level api which
+ is responsible for transferring the datas from host controller
+ to flash device and vice versa.
+
+Testing
+-------
+A seperated file named README.dra_qspi_test has been created which gives all the
+details about the commands required to test qspi at u-boot level.
diff --git a/marvell/uboot/doc/SPI/status.txt b/marvell/uboot/doc/SPI/status.txt
new file mode 100644
index 0000000..13889f5
--- /dev/null
+++ b/marvell/uboot/doc/SPI/status.txt
@@ -0,0 +1,32 @@
+Status on SPI subsystem:
+=======================
+
+SPI COMMAND (common/cmd_sf, cmd_spi):
+-
+
+SPI FLASH (drivers/mtd/spi):
+- sf_probe.c: SPI flash probing code.
+- sf_ops.c: SPI flash operations code.
+- sf.c: SPI flash interface, which interacts controller driver.
+- Bank Address Register (Accessing flashes > 16Mbytes in 3-byte addressing)
+- Added memory_mapped support for read operations.
+- Common probe support for all supported flash vendors except, ramtron.
+- Extended read commands support(dual read, dual IO read)
+- Quad Page Program support.
+- Quad Read support(quad fast read, quad IO read)
+- Dual flash connection topology support(accessing two spi flash memories with single cs)
+- Banking support on dual flash connection topology.
+
+SPI DRIVERS (drivers/spi):
+-
+
+TODO:
+- Runtime detection of spi_flash params, SFDP(if possible)
+- Add support for multibus build/accessing.
+- Need proper cleanups on spi_flash and drivers.
+
+--
+Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+18-09-2013.
+07-10-2013.
+08-01-2014.
diff --git a/marvell/uboot/doc/SPL/README.am335x-network b/marvell/uboot/doc/SPL/README.am335x-network
new file mode 100644
index 0000000..9b63791
--- /dev/null
+++ b/marvell/uboot/doc/SPL/README.am335x-network
@@ -0,0 +1,92 @@
+USING AM335x NETBOOT FEATURE
+
+ Some boards (like TI AM335x based ones) have quite big on-chip RAM and
+have support for booting via network in ROM. The following describes
+how to setup network booting and then optionally use this support to flash
+NAND and bricked (empty) board with only a network cable.
+
+ I. Building the required images
+ 1. You have to enable generic SPL configuration options (see
+doc/README.SPL) as well as CONFIG_SPL_NET_SUPPORT,
+CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and
+CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build
+SPL with support for booting over the network. Also you have to enable
+the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your
+board needs some board-specific initialization (TI AM335x EVM does).
+If you want SPL to use some Vendor Class Identifier (VCI) you can set
+one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration
+comes with support for network booting preconfigured.
+ 2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick
+script after boot:
+#define CONFIG_BOOTCOMMAND \
+ "setenv autoload no; " \
+ "bootp; " \
+ "if tftp 80000000 debrick.scr; then " \
+ "source 80000000; " \
+ "fi"
+(Or create additional board configuration with such option).
+ 3. Build U-Boot as usual
+ $ make <your_board_name>
+ You will need u-boot.img and spl/u-boot.bin images to perform
+network boot. Copy them to u-boot-restore.img and
+u-boot-spl-restore.bin respectively to distinguish this version
+(with automatic restore running) from the main one.
+
+ II. Host configuration.
+ 1. Setup DHCP server (recommended server is ISC DHCPd).
+ - Install DHCP server and setup it to listen on the interface you
+chose to connect to the board (usually configured in
+/etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there
+are no other active DHCP servers in the same network segment.
+ - Edit your dhcpd.conf and subnet declaration matching the address
+on the interface. Specify the range of assigned addresses and bootfile
+to use. IMPORTANT! Both RBL and SPL use the image filename provided
+in the BOOTP reply but obviously they need different images (RBL needs
+raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot
+image -- u-boot-restore.img). So you have to configure DHCP server to
+provide different image filenames to RBL and SPL (and possibly another
+one to main U-Boot). This can be done by checking Vendor Class
+Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0"
+and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option,
+see above).
+ - If you plan to use TFTP server on another machine you have to set
+server-name option to point to it.
+ - Here is sample configuration for ISC DHCPd, assuming the interface
+used to connect to the board is eth0, and it has address 192.168.8.1:
+
+subnet 192.168.8.0 netmask 255.255.255.0 {
+ range dynamic-bootp 192.168.8.100 192.168.8.199;
+
+ if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
+ filename "u-boot-spl-restore.bin";
+ } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
+ filename "u-boot-restore.img";
+ } else {
+ filename "uImage";
+ }
+}
+
+ 2. Setup TFTP server.
+ Install TFTP server and put image files to it's root directory
+(likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need
+u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory.
+
+ III. Reflashing (debricking) the board.
+ 1. Write debrick script. You will need to write a script that will
+be executed after network boot to perform actual rescue actions. You
+can use usual U-Boot commands from this script: tftp to load additional
+files, nand erase/nand write to erase/write the NAND flash.
+
+ 2. Create script image from your script. From U-Boot build directory:
+
+$ ./tools/mkimage -A arm -O U-Boot -C none -T script -d <your script> debrick.scr
+
+This will create debrick.scr file with your script inside.
+
+ 3. Copy debrick.scr to TFTP root directory. You also need to copy
+there all the files your script tries to load via TFTP. Example script
+loads u-boot.img and MLO. You have to create these files doing regular
+(not restore_flash) build and copy them to tftpboot directory.
+
+ 4. Boot the board from the network, U-Boot will load debrick script
+and run it after boot.
diff --git a/marvell/uboot/doc/SPL/README.omap3 b/marvell/uboot/doc/SPL/README.omap3
new file mode 100644
index 0000000..c77ca43
--- /dev/null
+++ b/marvell/uboot/doc/SPL/README.omap3
@@ -0,0 +1,52 @@
+Overview of SPL on OMAP3 devices
+================================
+
+Introduction
+------------
+
+This document provides an overview of how SPL functions on OMAP3 (and related
+such as am35x and am37x) processors.
+
+Methodology
+-----------
+
+On these platforms the ROM supports trying a sequence of boot devices. Once
+one has been used successfully to load SPL this information is stored in memory
+and the location stored in a register. We will read this to determine where to
+read U-Boot from in turn.
+
+Memory Map
+----------
+
+This is an example of a typical setup. See top-level README for documentation
+of which CONFIG variables control these values. For a given board and the
+amount of DRAM available to it different values may need to be used.
+Note that the size of the SPL text rodata and data is enforced with a CONFIG
+option and growing over that size results in a link error. The SPL stack
+starts at the top of SRAM (which is configurable) and grows downward. The
+space between the top of SRAM and the enforced upper bound on the size of the
+SPL text, data and rodata is considered the safe stack area. Details on
+confirming this behavior are shown below.
+
+A portion of the system memory map looks as follows:
+SRAM: 0x40200000 - 0x4020FFFF
+DDR1: 0x80000000 - 0xBFFFFFFF
+
+Option 1 (SPL only):
+0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
+0x4020E000 - 0x4020FFFC: Area for the SPL stack.
+0x80000000 - 0x8007FFFF: Area for the SPL BSS.
+0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
+0x80208000 - 0x80307FFF: malloc() pool available to SPL.
+
+Option 2 (SPL or X-Loader):
+0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
+0x4020E000 - 0x4020FFFC: Area for the SPL stack.
+0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
+0x87000000 - 0x8707FFFF: Area for the SPL BSS.
+0x87080000 - 0x870FFFFF: malloc() pool available to SPL.
+
+For the areas that reside within DDR1 they must not be used prior to s_init()
+completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL
+uses while running. This is why we have two versions of the memory map that
+only vary in where the BSS and malloc pool reside.
diff --git a/marvell/uboot/doc/device-tree-bindings/README b/marvell/uboot/doc/device-tree-bindings/README
new file mode 100644
index 0000000..2ea3439
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/README
@@ -0,0 +1,17 @@
+Device Tree Bindings Staging Area
+=================================
+
+This directory contains device tree bindings for U-Boot.
+
+These follow along with Linux kernel bindings, with a few additions. By
+adding the files here, U-Boot patches can clearly show thees additions.
+This makes it easier for device tree people to review these additions in
+patches sent to the U-Boot mailing list.
+
+The intent IS to commit these files to U-Boot. Hopefully at some point
+the files will be stored in another repo (shared with Linux) which is
+brought in as needed. Changes here are intended to mirror changes in the
+Linux Documentation/devicetree/bindings/ directory.
+
+sjg@chromium.org
+17-Jan-12
diff --git a/marvell/uboot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt b/marvell/uboot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 0000000..5c07fca
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,207 @@
+NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra20-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+
+ The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. These IDs often match those in the CAR's RST_DEVICES registers,
+ but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+ this case, those clocks are assigned IDs above 95 in order to highlight
+ this issue. Implementations that interpret these clock IDs as bit values
+ within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+ explicitly handle these special cases.
+
+ The balance of the clocks controlled by the CAR are assigned IDs of 96 and
+ above.
+
+ 0 cpu
+ 1 unassigned
+ 2 unassigned
+ 3 ac97
+ 4 rtc
+ 5 tmr
+ 6 uart1
+ 7 unassigned (register bit affects uart2 and vfir)
+ 8 gpio
+ 9 sdmmc2
+ 10 unassigned (register bit affects spdif_in and spdif_out)
+ 11 i2s1
+ 12 i2c1
+ 13 ndflash
+ 14 sdmmc1
+ 15 sdmmc4
+ 16 twc
+ 17 pwm
+ 18 i2s2
+ 19 epp
+ 20 unassigned (register bit affects vi and vi_sensor)
+ 21 2d
+ 22 usbd
+ 23 isp
+ 24 3d
+ 25 ide
+ 26 disp2
+ 27 disp1
+ 28 host1x
+ 29 vcp
+ 30 unassigned
+ 31 cache2
+
+ 32 mem
+ 33 ahbdma
+ 34 apbdma
+ 35 unassigned
+ 36 kbc
+ 37 stat_mon
+ 38 pmc
+ 39 fuse
+ 40 kfuse
+ 41 sbc1
+ 42 snor
+ 43 spi1
+ 44 sbc2
+ 45 xio
+ 46 sbc3
+ 47 dvc
+ 48 dsi
+ 49 unassigned (register bit affects tvo and cve)
+ 50 mipi
+ 51 hdmi
+ 52 csi
+ 53 tvdac
+ 54 i2c2
+ 55 uart3
+ 56 unassigned
+ 57 emc
+ 58 usb2
+ 59 usb3
+ 60 mpe
+ 61 vde
+ 62 bsea
+ 63 bsev
+
+ 64 speedo
+ 65 uart4
+ 66 uart5
+ 67 i2c3
+ 68 sbc4
+ 69 sdmmc3
+ 70 pcie
+ 71 owr
+ 72 afi
+ 73 csite
+ 74 unassigned
+ 75 avpucq
+ 76 la
+ 77 unassigned
+ 78 unassigned
+ 79 unassigned
+ 80 unassigned
+ 81 unassigned
+ 82 unassigned
+ 83 unassigned
+ 84 irama
+ 85 iramb
+ 86 iramc
+ 87 iramd
+ 88 cram2
+ 89 audio_2x a/k/a audio_2x_sync_clk
+ 90 clk_d
+ 91 unassigned
+ 92 sus
+ 93 cdev1
+ 94 cdev2
+ 95 unassigned
+
+ 96 uart2
+ 97 vfir
+ 98 spdif_in
+ 99 spdif_out
+ 100 vi
+ 101 vi_sensor
+ 102 tvo
+ 103 cve
+ 104 osc
+ 105 clk_32k a/k/a clk_s
+ 106 clk_m
+ 107 sclk
+ 108 cclk
+ 109 hclk
+ 110 pclk
+ 111 blink
+ 112 pll_a
+ 113 pll_a_out0
+ 114 pll_c
+ 115 pll_c_out1
+ 116 pll_d
+ 117 pll_d_out0
+ 118 pll_e
+ 119 pll_m
+ 120 pll_m_out1
+ 121 pll_p
+ 122 pll_p_out1
+ 123 pll_p_out2
+ 124 pll_p_out3
+ 125 pll_p_out4
+ 126 pll_s
+ 127 pll_u
+ 128 pll_x
+ 129 cop a/k/a avp
+ 130 audio a/k/a audio_sync_clk
+
+Example SoC include file:
+
+/ {
+ tegra_car: clock@60006000 {
+ compatible = "nvidia,tegra20-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ usb@c5004000 {
+ clocks = <&tegra_car 58>; /* usb2 */
+ };
+};
+
+Example board file:
+
+/ {
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+ };
+
+ i2c@7000d000 {
+ pmic@34 {
+ compatible = "ti,tps6586x";
+ reg = <0x34>;
+
+ clk_32k: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+ };
+
+ &tegra_car {
+ clocks = <&clk_32k> <&osc>;
+ };
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/exynos/dwmmc.txt b/marvell/uboot/doc/device-tree-bindings/exynos/dwmmc.txt
new file mode 100644
index 0000000..566da3b
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/exynos/dwmmc.txt
@@ -0,0 +1,54 @@
+* Exynos 5250 DWC_mobile_storage
+
+The Exynos 5250 provides DWC_mobile_storage interface which supports
+. Embedded Multimedia Cards (EMMC-version 4.5)
+. Secure Digital memory (SD mem-version 2.0)
+. Secure Digital I/O (SDIO-version 3.0)
+. Consumer Electronics Advanced Transport Architecture (CE-ATA-version 1.1)
+
+The Exynos 5250 DWC_mobile_storage provides four channels.
+SOC specific and Board specific properties are channel specific.
+
+Required SoC Specific Properties:
+
+- compatible: should be
+ - samsung,exynos5250-dwmmc: for exynos5250 platforms
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- samsung,bus-width: The width of the bus used to interface the devices
+ supported by DWC_mobile_storage (SD-MMC/EMMC/SDIO).
+ . Typically the bus width is 4 or 8.
+- samsung,timing: The timing values to be written into the
+ Drv/sample clock selection register of corresponding channel.
+ . It is comprised of 3 values corresponding to the 3 fileds
+ 'SelClk_sample', 'SelClk_drv' and 'DIVRATIO' of CLKSEL register.
+ . SelClk_sample: Select sample clock among 8 shifted clocks.
+ . SelClk_drv: Select drv clock among 8 shifted clocks.
+ . DIVRATIO: Clock Divide ratio select.
+ . The above 3 values are used by the clock phase shifter.
+
+Example:
+
+mmc@12200000 {
+ samsung,bus-width = <8>;
+ samsung,timing = <1 3 3>;
+ samsung,removable = <1>;
+}
+In the above example,
+ . The bus width is 8
+ . Timing is comprised of 3 values as explained below
+ 1 - SelClk_sample
+ 3 - SelClk_drv
+ 3 - DIVRATIO
+ . The 'removable' flag indicates whether the the particilar device
+ cannot be removed (always present) or it is a removable device.
+ 1 - Indicates that the device is removable.
+ 0 - Indicates that the device cannot be removed.
diff --git a/marvell/uboot/doc/device-tree-bindings/exynos/isp-spi.txt b/marvell/uboot/doc/device-tree-bindings/exynos/isp-spi.txt
new file mode 100644
index 0000000..b8086e8
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/exynos/isp-spi.txt
@@ -0,0 +1,22 @@
+Exynos ISP SPI Subsystem
+
+The device node for ISP SPI subsytem.
+Since Peripheral id in EXYNOS is decoded based on Interrupts, currently
+ISP SPI have no individual interrupts hence we add ad dummy interrupt node
+which will have a value beyond the maximum number of interrupts exynos5 can
+support.
+
+Required properties :
+ - compatible : Should be "samsung,exynos-spi" for spi.
+ - reg : Base adrress of the the subsystem.
+ - interrupts : A value which is beyond the maximum number of interrupts
+exynos5 can support.
+
+Example:
+spi@131a0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos-spi";
+ reg = <0x131a0000 0x30>;
+ interrupts = <0 129 0>;
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/exynos/sound.txt b/marvell/uboot/doc/device-tree-bindings/exynos/sound.txt
new file mode 100644
index 0000000..98d1798
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/exynos/sound.txt
@@ -0,0 +1,27 @@
+Exynos Sound Subsystem
+
+The device node for sound subsytem which contains codec and i2s block
+that is a part of Exynos5250
+
+Required properties :
+ - compatible : Should be "samsung,exynos-sound" for sound
+ - samsung,i2s-epll-clock-frequency : epll clock output frequency in Hz
+ - samsung,i2s-sampling-rate : sampling rate, default is 48000
+ - samsung,i2s-bits-per-sample : sample width, defalut is 16 bit
+ - samsung,i2s-channels : nummber of channels, default is 2
+ - samsung,i2s-lr-clk-framesize : lr clock frame size
+ - samsung,i2s-bit-clk-framesize : bit clock frame size
+ - samsung,codec-type : sound codec type
+
+Example:
+
+sound@12d60000 {
+ compatible = "samsung,exynos-sound"
+ samsung,i2s-epll-clock-frequency = <192000000>;
+ samsung,i2s-sampling-rate = <48000>;
+ samsung,i2s-bits-per-sample = <16>;
+ samsung,i2s-channels = <2>;
+ samsung,i2s-lr-clk-framesize = <256>;
+ samsung,i2s-bit-clk-framesize = <32>;
+ samsung,codec-type = "wm8994";
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/exynos/tmu.txt b/marvell/uboot/doc/device-tree-bindings/exynos/tmu.txt
new file mode 100644
index 0000000..89d3bf0
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/exynos/tmu.txt
@@ -0,0 +1,44 @@
+Exynos Thermal management Unit
+
+Required properties:
+
+ - compatible : Should be "samsung,exynos-tmu" for TMU
+ - samsung,min-temp : Minimum temperature value (25 degree celsius)
+ - Current temperature of SoC should be more than this value.
+ - samsung,max-temp : Maximum temperature value (125 degree celsius)
+ - Current temperature of SoC should be less than this value.
+ - samsung,start-warning : Temperature at which TMU starts giving warning (degree celsius)
+ - samsung,start-tripping : Temperature at which TMU shuts down the system (degree celsius)
+ - samsung,hw-tripping : Temperature at which hardware tripping should happen
+ in case TMU fails to power off (degree celsius)
+ - samsung,efuse-min-value : SOC efuse min value (Constant 40)
+ - efuse-value should be more than this value.
+ - samsung,efuse-value : SOC actual efuse value (Literal value)
+ - This is the data trimming info.
+ - This value is used to calculate measuring error.
+ - samsung,efuse-max-value : SoC max efuse value (Constant 100)
+ - efuse-value should be less than this value.
+ - samsung,slope : Default value 274761730 (Constant 0x1060_8802).
+ - This is the default value for TMU_CONTROL register.
+ - It sets the gain of amplifier to the positive-tc generator block.
+ - It selects thermal tripping mode and enables thermal tripping.
+ - samsung,dc-value : Measured data calibration value (Constant 25)
+ - Used for tempearture calculation.
+ - This is 25 because temperature measured is always above 25 degrees.
+
+
+Example:
+
+tmu@10060000 {
+ compatible = "samsung,exynos-tmu"
+ samsung,min-temp = <25>;
+ samsung,max-temp = <125>;
+ samsung,start-warning = <95>;
+ samsung,start-tripping = <105>;
+ samsung,hw-tripping = <110>;
+ samsung,efuse-min-value = <40>;
+ samsung,efuse-value = <55>;
+ samsung,efuse-max-value = <100>;
+ samsung,slope = <274761730>;
+ samsung,dc-value = <25>;
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/i2c/tegra20-i2c.txt b/marvell/uboot/doc/device-tree-bindings/i2c/tegra20-i2c.txt
new file mode 100644
index 0000000..72649df
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/i2c/tegra20-i2c.txt
@@ -0,0 +1,23 @@
+(Placeholder note while we locate the kernel Tegra20 bindings)
+
+Added in U-Boot:
+
+Required properties:
+ - clocks : Two clocks must be given, each as a phandle to the Tegra's
+ CAR node and the clock number as a parameter:
+ - the I2C clock to use for the peripheral
+ - the pll_p_out3 clock, which can be used for fast operation. This
+ does not change and is the same for all I2C nodes.
+
+Example:
+(TODO: merge with existing example):
+
+ i2c@7000c400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,tegra20-i2c";
+ reg = <0x7000C400 0x100>;
+ interrupts = < 116 >;
+ /* PERIPH_ID_I2C2, PLL_P_OUT3 */
+ clocks = <&tegra_car 54>, <&tegra_car 124>;
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/input/cros-ec-keyb.txt b/marvell/uboot/doc/device-tree-bindings/input/cros-ec-keyb.txt
new file mode 100644
index 0000000..3118276
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,79 @@
+CROS_EC Keyboard
+
+The CROS_EC (Matrix Keyboard Protocol) allows communcation with a secondary
+micro used for keyboard, and possible other features.
+
+The CROS_EC keyboard uses this protocol to receive key scans and produce input
+in U-Boot.
+
+Required properties :
+- compatible : "google,cros-ec-keyb"
+- google,key-rows : Number of key rows
+- google,key-columns : Number of key columns
+
+Optional properties, in addition to those specified by the shared
+matrix-keyboard bindings:
+
+- linux,fn-keymap: a second keymap, same specification as the
+ matrix-keyboard-controller spec but to be used when the KEY_FN modifier
+ key is pressed.
+- google,repeat-delay-ms : delay in milliseconds before repeat starts
+- google,repeat-rate-ms : delay between each subsequent key press
+- google,ghost-filter : enable ghost filtering for this device
+
+Example, taken from daisy:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,ghost-filter;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003c 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/misc/cros-ec.txt b/marvell/uboot/doc/device-tree-bindings/misc/cros-ec.txt
new file mode 100644
index 0000000..07ea7cd
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/misc/cros-ec.txt
@@ -0,0 +1,38 @@
+Chrome OS CROS_EC Binding
+======================
+
+The device tree node which describes the operation of the CROS_EC interface
+is as follows:
+
+Required properties :
+- compatible = "google,cros-ec"
+
+Optional properties :
+- spi-max-frequency : Sets the maximum frequency (in Hz) for SPI bus
+ operation
+- i2c-max-frequency : Sets the maximum frequency (in Hz) for I2C bus
+ operation
+- ec-interrupt : Selects the EC interrupt, defined as a GPIO according
+ to the platform
+- optimise-flash-write : Boolean property - if present then flash blocks
+ containing all 0xff will not be written, since we assume that the EC
+ uses that pattern for erased blocks
+
+The CROS_EC node should appear as a subnode of the interrupt that connects it
+to the EC (e.g. i2c, spi, lpc). The reg property (as usual) will indicate
+the unit address on that bus.
+
+
+Example
+=======
+
+ spi@131b0000 {
+ cros-ec@0 {
+ reg = <0>;
+ compatible = "google,cros-ec";
+ spi-max-frequency = <5000000>;
+ ec-interrupt = <&gpio 174 1>;
+ optimise-flash-write;
+ status = "disabled";
+ };
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt b/marvell/uboot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt
new file mode 100644
index 0000000..86ae408
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt
@@ -0,0 +1,53 @@
+NAND Flash
+----------
+
+(there isn't yet a generic binding in Linux, so this describes what is in
+U-Boot. There should not be Linux-specific or U-Boot specific binding, just
+a binding that describes this hardware. But agreeing a binding in Linux in
+the absence of a driver may be beyond my powers.)
+
+The device node for a NAND flash device is as follows:
+
+Required properties :
+ - compatible : Should be "manufacturer,device", "nand-flash"
+
+This node should sit inside its controller.
+
+
+Nvidia NAND Controller
+----------------------
+
+The device node for a NAND flash controller is as follows:
+
+Optional properties:
+
+nvidia,wp-gpios : GPIO of write-protect line, three cells in the format:
+ phandle, parameter, flags
+nvidia,nand-width : bus width of the NAND device in bits
+
+ - nvidia,nand-timing : Timing parameters for the NAND. Each is in ns.
+ Order is: MAX_TRP_TREA, TWB, Max(tCS, tCH, tALS, tALH),
+ TWHR, Max(tCS, tCH, tALS, tALH), TWH, TWP, TRH, TADL
+
+ MAX_TRP_TREA is:
+ non-EDO mode: Max(tRP, tREA) + 6ns
+ EDO mode: tRP timing
+
+The 'reg' property should provide the chip select used by the flash chip.
+
+
+Example
+-------
+
+nand-controller@0x70008000 {
+ compatible = "nvidia,tegra20-nand";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nvidia,wp-gpios = <&gpio 59 0>; /* PH3 */
+ nvidia,nand-width = <8>;
+ nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+ nand@0 {
+ reg = <0>;
+ compatible = "hynix,hy27uf4g2b", "nand-flash";
+ };
+};
diff --git a/marvell/uboot/doc/device-tree-bindings/pwm/tegra20-pwm.txt b/marvell/uboot/doc/device-tree-bindings/pwm/tegra20-pwm.txt
new file mode 100644
index 0000000..01438ec
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/pwm/tegra20-pwm.txt
@@ -0,0 +1,18 @@
+Tegra SoC PWFM controller
+
+Required properties:
+- compatible: should be one of:
+ - "nvidia,tegra20-pwm"
+ - "nvidia,tegra30-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
+ first cell specifies the per-chip index of the PWM to use and the second
+ cell is the period in nanoseconds.
+
+Example:
+
+ pwm: pwm@7000a000 {
+ compatible = "nvidia,tegra20-pwm";
+ reg = <0x7000a000 0x100>;
+ #pwm-cells = <2>;
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/spi/spi-bus.txt b/marvell/uboot/doc/device-tree-bindings/spi/spi-bus.txt
new file mode 100644
index 0000000..800dafe
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/spi/spi-bus.txt
@@ -0,0 +1,92 @@
+SPI (Serial Peripheral Interface) busses
+
+SPI busses can be described with a node for the SPI master device
+and a set of child nodes for each SPI slave on the bus. For this
+discussion, it is assumed that the system's SPI controller is in
+SPI master mode. This binding does not describe SPI controllers
+in slave mode.
+
+The SPI master node requires the following properties:
+- #address-cells - number of cells required to define a chip select
+ address on the SPI bus.
+- #size-cells - should be zero.
+- compatible - name of SPI bus controller following generic names
+ recommended practice.
+- cs-gpios - (optional) gpios chip select.
+No other properties are required in the SPI bus node. It is assumed
+that a driver for an SPI bus device will understand that it is an SPI bus.
+However, the binding does not attempt to define the specific method for
+assigning chip select numbers. Since SPI chip select configuration is
+flexible and non-standardized, it is left out of this binding with the
+assumption that board specific platform code will be used to manage
+chip selects. Individual drivers can define additional properties to
+support describing the chip select layout.
+
+Optional property:
+- num-cs : total number of chipselects
+
+If cs-gpios is used the number of chip select will automatically increased
+with max(cs-gpios > hw cs)
+
+So if for example the controller has 2 CS lines, and the cs-gpios
+property looks like this:
+
+cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;
+
+Then it should be configured so that num_chipselect = 4 with the
+following mapping:
+
+cs0 : &gpio1 0 0
+cs1 : native
+cs2 : &gpio1 1 0
+cs3 : &gpio1 2 0
+
+SPI slave nodes must be children of the SPI master node and can
+contain the following properties.
+- reg - (required) chip select address of device.
+- compatible - (required) name of SPI device following generic names
+ recommended practice
+- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
+- spi-cpol - (optional) Empty property indicating device requires
+ inverse clock polarity (CPOL) mode
+- spi-cpha - (optional) Empty property indicating device requires
+ shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device requires
+ chip select active high
+- spi-3wire - (optional) Empty property indicating device requires
+ 3-wire mode.
+- spi-tx-bus-width - (optional) The bus width(number of data wires) that
+ used for MOSI. Defaults to 1 if not present.
+- spi-rx-bus-width - (optional) The bus width(number of data wires) that
+ used for MISO. Defaults to 1 if not present.
+
+Some SPI controllers and devices support Dual and Quad SPI transfer mode.
+It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD).
+Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
+only 1(SINGLE), 2(DUAL) and 4(QUAD).
+Dual/Quad mode is not allowed when 3-wire mode is used.
+
+If a gpio chipselect is used for the SPI slave the gpio number will be passed
+via the cs_gpio
+
+SPI example for an MPC5200 SPI bus:
+ spi@f00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+ reg = <0xf00 0x20>;
+ interrupts = <2 13 0 2 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+
+ codec@1 {
+ compatible = "ti,tlv320aic26";
+ spi-max-frequency = <100000>;
+ reg = <1>;
+ };
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/usb/tegra-usb.txt b/marvell/uboot/doc/device-tree-bindings/usb/tegra-usb.txt
new file mode 100644
index 0000000..5282d44
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/usb/tegra-usb.txt
@@ -0,0 +1,25 @@
+Tegra SOC USB controllers
+
+The device node for a USB controller that is part of a Tegra
+SOC is as described in the document "Open Firmware Recommended
+Practice : Universal Serial Bus" with the following modifications
+and additions :
+
+Required properties :
+ - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
+ used in host mode.
+ - phy_type : Should be one of "ulpi" or "utmi".
+ - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+
+Optional properties:
+ - dr_mode : dual role mode. Indicates the working mode for
+ nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
+ or "otg". Default to "host" if not defined for backward compatibility.
+ host means this is a host controller
+ peripheral means it is device controller
+ otg means it can operate as either ("on the go")
+ - nvidia,has-legacy-mode : boolean indicates whether this controller can
+ operate in legacy mode (as APX 2500 / 2600). In legacy mode some
+ registers are accessed through the APB_MISC base address instead of
+ the USB controller.
diff --git a/marvell/uboot/doc/device-tree-bindings/video/displaymode.txt b/marvell/uboot/doc/device-tree-bindings/video/displaymode.txt
new file mode 100644
index 0000000..45ca42d
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/video/displaymode.txt
@@ -0,0 +1,42 @@
+videomode bindings
+==================
+
+(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html)
+
+Required properties:
+ - xres, yres: Display resolution
+ - left-margin, right-margin, hsync-len: Horizontal Display timing
+ parameters in pixels
+ - upper-margin, lower-margin, vsync-len: Vertical display timing
+ parameters in lines
+ - clock: display clock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree
+representation corresponds to the one used by the Linux Framebuffer
+framework described here in Documentation/fb/framebuffer.txt. This
+representation has been chosen because it's the only format which does
+not allow for inconsistent parameters. Unlike the Framebuffer framework
+the devicetree has the clock in Hz instead of ps.
+
+Example:
+
+ display@0 {
+ /* 1920x1080p24 */
+ clock = <52000000>;
+ xres = <1920>;
+ yres = <1080>;
+ left-margin = <25>;
+ right-margin = <25>;
+ hsync-len = <25>;
+ lower-margin = <2>;
+ upper-margin = <2>;
+ vsync-len = <2>;
+ hsync-active-high;
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/video/exynos-dp.txt b/marvell/uboot/doc/device-tree-bindings/video/exynos-dp.txt
new file mode 100644
index 0000000..464a853
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/video/exynos-dp.txt
@@ -0,0 +1,69 @@
+Exynos Display port controller
+==============================
+
+Required properties:
+SOC specific:
+ compatible: should be "samsung,exynos5-dp"
+ reg: Base address of DP IP
+
+Optional properties:
+ samsung,h-res: X resolution of the panel
+ samsung,h-sync-width: hsync value
+ samsung,h-back-porch: left margin
+ samsung,h-front-porch right margin
+ samsung,v-res: Y resolution of the panel
+ samsung,v-sync-width: vsync value
+ samsung,v-back-porch: upper margin
+ samsung,v-front-porch: lower margin
+ samsung,v-sync-rate: refresh rate
+
+ samsung,lt-status: Link training status
+ 0(DP_LT_NONE), 1(DP_LT_START), 2(DP_LT_CR), 3(DP_LT_ET),
+ 4(DP_LT_FINISHED), 5(DP_LT_FAIL)
+
+ samsung,master-mode: 1 if you want to run DP as master, else 0
+ samsung,bist-mode: 1 to enable video bist mode, else 0
+ samsung,bist-pattern: bist mode pattern type
+ 0(NO_PATTERN), 1(COLOR_RAMP), 2(BALCK_WHITE_V_LINES),
+ 3(COLOR_SQUARE), 4(INVALID_PATTERN), 5(COLORBAR_32),
+ 6(COLORBAR_64),7(WHITE_GRAY_BALCKBAR_32),
+ 8(WHITE_GRAY_BALCKBAR_64),9(MOBILE_WHITEBAR_32),
+ 10(MOBILE_WHITEBAR_64)
+ samsung,h-sync-polarity: Horizontal Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,v-sync-polarity: Vertical Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,interlaced: Progressive if 0, else Interlaced
+ samsung,color-space: input video data format
+ COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+ samsung,dynamic-range: dynamic range for input video data
+ VESA = 0, CEA = 1
+ samsung,ycbcr-coeff: YCbCr co-efficients for input video
+ COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
+ samsung,color-depth: number of bits per colour component
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+
+Example:
+SOC specific part:
+ dp@145b0000 {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b0000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+Board(panel) specific part:
+ dp@145b0000 {
+ samsung,lt-status = <0>;
+
+ samsung,master-mode = <0>;
+ samsung,bist-mode = <0>;
+ samsung,bist-pattern = <0>;
+ samsung,h-sync-polarity = <0>;
+ samsung,v-sync-polarity = <0>;
+ samsung,interlaced = <0>;
+ samsung,color-space = <0>;
+ samsung,dynamic-range = <0>;
+ samsung,ycbcr-coeff = <0>;
+ samsung,color-depth = <1>;
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/video/exynos-fb.txt b/marvell/uboot/doc/device-tree-bindings/video/exynos-fb.txt
new file mode 100644
index 0000000..bb7441c
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/video/exynos-fb.txt
@@ -0,0 +1,92 @@
+Exynos Display Controller
+=========================
+Required properties:
+SOC specific:
+ compatible: should be "samsung,exynos-fimd"
+ reg: Base address of FIMD IP.
+
+Board(panel specific):
+ samsung,vl-col: X resolution of the panel
+ samsung,vl-row: Y resolution of the panel
+ samsung,vl-freq: Refresh rate
+ samsung,vl-bpix: Bits per pixel
+ samsung,vl-hspw: Hsync value
+ samsung,vl-hfpd: Right margin
+ samsung,vl-hbpd: Left margin
+ samsung,vl-vspw: Vsync value
+ samsung,vl-vfpd: Lower margin
+ samsung,vl-vbpd: Upper margin
+
+Optional properties:
+Board(panel specific):
+ samsung,vl-width: width of display area in mm
+ samsung,vl-height: Height of display area in mm
+
+ samsung,vl-clkp: Clock polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-oep: Output Enable polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-hsp: Horizontal Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-vsp: Vertical Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-dp: Data polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+
+ samsung,vl-cmd-allow-len: Wait end of frame
+ samsung,winid: Window number on which data is to be displayed
+ samsung,init-delay: Delay before LCD initialization starts
+ samsung,power-on-delay: Delay after LCD is powered on
+ samsung,reset-delay: Delay after LCD is reset
+ samsung,interface-mode: 1(FIMD_RGB_INTERFACE), 2(FIMD_CPU_INTERFACE)
+ samsung,mipi-enabled: 1 if you want to use MIPI, else 0
+ samsung,dp-enabled: 1is you want to use DP, else 0
+ samsung,cs-setup: cs_setup value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-setup: wr_setup value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-act: wr_act value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-hold: wr_hold value in FIMD_CPU_INTERFACE mode.
+ samsung,logo-on: 1 if you want to use custom logo.
+ 0 if you want LCD console.
+ samsung,logo-width: pixel width of logo image. Valid if logo_on = 1
+ samsung,logo-height: pixel height of logo image. Valid if logo_on = 1
+ samsung,logo-addr: Address of logo image. Valid if logo_on = 1
+ samsung,rgb-mode: 0(MODE_RGB_P), 1(MODE_BGR_P),
+ 2(MODE_RGB_S), 3(MODE_BGR_S)
+ samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL)
+ samsung,sclk-div: parent_clock/source_clock ratio
+ samsung,dual-lcd-enabled: 1 if you support two LCD, else 0
+
+Example:
+SOC specific part:
+ fimd@14400000 {
+ compatible = "samsung,exynos-fimd";
+ reg = <0x14400000 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+Board specific part:
+ fimd@14400000 {
+ samsung,vl-freq = <60>;
+ samsung,vl-col = <2560>;
+ samsung,vl-row = <1600>;
+ samsung,vl-width = <2560>;
+ samsung,vl-height = <1600>;
+
+ samsung,vl-clkp;
+ samsung,vl-dp;
+ samsung,vl-bpix = <4>;
+
+ samsung,vl-hspw = <32>;
+ samsung,vl-hbpd = <80>;
+ samsung,vl-hfpd = <48>;
+ samsung,vl-vspw = <6>;
+ samsung,vl-vbpd = <37>;
+ samsung,vl-vfpd = <3>;
+ samsung,vl-cmd-allow-len = <0xf>;
+
+ samsung,winid = <3>;
+ samsung,interface-mode = <1>;
+ samsung,dp-enabled = <1>;
+ samsung,dual-lcd-enabled = <0>;
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/video/simple-framebuffer.txt b/marvell/uboot/doc/device-tree-bindings/video/simple-framebuffer.txt
new file mode 100644
index 0000000..3ea4605
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+ - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+
+Example:
+
+ framebuffer {
+ compatible = "simple-framebuffer";
+ reg = <0x1d385000 (1600 * 1200 * 2)>;
+ width = <1600>;
+ height = <1200>;
+ stride = <(1600 * 2)>;
+ format = "r5g6b5";
+ };
diff --git a/marvell/uboot/doc/device-tree-bindings/video/tegra20-dc.txt b/marvell/uboot/doc/device-tree-bindings/video/tegra20-dc.txt
new file mode 100644
index 0000000..4731c3f
--- /dev/null
+++ b/marvell/uboot/doc/device-tree-bindings/video/tegra20-dc.txt
@@ -0,0 +1,85 @@
+Display Controller
+------------------
+
+(there isn't yet a generic binding in Linux, so this describes what is in
+U-Boot, and may change based on Linux activity)
+
+The device node for a display device is as described in the document
+"Open Firmware Recommended Practice : Universal Serial Bus" with the
+following modifications and additions :
+
+Required properties :
+ - compatible : Should be "nvidia,tegra20-dc"
+
+Required subnode 'rgb' is as follows:
+
+Required properties (rgb) :
+ - nvidia,panel : phandle of LCD panel information
+
+
+The panel node describes the panel itself. This has the properties listed in
+displaymode.txt as well as:
+
+Required properties (panel) :
+ - nvidia,bits-per-pixel: number of bits per pixel (depth)
+ - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt)
+ - nvidia,panel-timings: 4 cells containing required timings in ms:
+ * delay before asserting panel_vdd
+ * delay between panel_vdd-rise and data-rise
+ * delay between data-rise and backlight_vdd-rise
+ * delay between backlight_vdd and pwm-rise
+ * delay between pwm-rise and backlight_en-rise
+
+Optional GPIO properies all have (phandle, GPIO number, flags):
+ - nvidia,backlight-enable-gpios: backlight enable GPIO
+ - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO
+ - nvidia,backlight-vdd-gpios: backlight power GPIO
+ - nvidia,panel-vdd-gpios: panel power GPIO
+
+Example:
+
+host1x {
+ compatible = "nvidia,tegra20-host1x", "simple-bus";
+ reg = <0x50000000 0x00024000>;
+ interrupts = <0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04>; /* mpcore general */
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ ranges = <0x54000000 0x54000000 0x04000000>;
+
+ dc@54200000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54200000 0x00040000>;
+ interrupts = <0 73 0x04>;
+ status = "okay";
+
+ rgb {
+ status = "okay";
+ nvidia,panel = <&lcd_panel>;
+ };
+ };
+};
+
+lcd_panel: panel {
+ /* Seaboard has 1366x768 */
+ clock = <70600000>;
+ xres = <1366>;
+ yres = <768>;
+ left-margin = <58>;
+ right-margin = <58>;
+ hsync-len = <58>;
+ lower-margin = <4>;
+ upper-margin = <4>;
+ vsync-len = <4>;
+ hsync-active-high;
+ nvidia,bits-per-pixel = <16>;
+ nvidia,pwm = <&pwm 2 0>;
+ nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */
+ nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */
+ nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */
+ nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */
+ nvidia,panel-timings = <400 4 203 17 15>;
+};
diff --git a/marvell/uboot/doc/driver-model/UDM-block.txt b/marvell/uboot/doc/driver-model/UDM-block.txt
new file mode 100644
index 0000000..0437d9b
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-block.txt
@@ -0,0 +1,278 @@
+The U-Boot Driver Model Project
+===============================
+Block device subsystem analysis
+===============================
+
+Pavel Herrmann <morpheus.ibis@gmail.com>
+2012-03-08
+
+I) Overview
+-----------
+
+ U-Boot currently implements several distinct APIs for block devices - some
+ drivers use the SATA API, some drivers use the IDE API, sym53c8xx and
+ AHCI use the SCSI API, mg_disk has a separate API, and systemace also has a
+ separate API. There are also MMC and USB APIs used outside of drivers/block,
+ those will be detailed in their specific documents.
+
+ Block devices are described by block_dev_desc structure, that holds, among
+ other things, the read/write/erase callbacks. Block device structures are
+ stored in any way depending on the API, but can be accessed by
+
+ block_dev_desc_t * $api_get_dev(int dev)
+
+ function, as seen in disk/part.c.
+
+ 1) SATA interface
+ -----------------
+
+ The SATA interface drivers implement the following functions:
+
+ int init_sata(int dev)
+ int scan_sata(int dev)
+ ulong sata_read(int dev, ulong blknr, ulong blkcnt, void *buffer)
+ ulong sata_write(int dev, ulong blknr, ulong blkcnt, const void *buffer)
+
+ Block devices are kept in sata_dev_desc[], which is prefilled with values
+ common to all SATA devices in cmd_sata.c, and then modified in init_sata
+ function in the drivers. Callbacks of the block device use SATA API
+ directly. The sata_get_dev function is defined in cmd_sata.c.
+
+ 2) SCSI interface
+ -----------------
+
+ The SCSI interface drivers implement the following functions:
+
+ void scsi_print_error(ccb *pccb)
+ int scsi_exec(ccb *pccb)
+ void scsi_bus_reset(void)
+ void scsi_low_level_init(int busdevfunc)
+
+ The SCSI API works through the scsi_exec function, the actual operation
+ requested is found in the ccb structure.
+
+ Block devices are kept in scsi_dev_desc[], which lives only in cmd_scsi.c.
+ Callbacks of the block device use functions from cmd_scsi.c, which in turn
+ call scsi_exec of the controller. The scsi_get_dev function is also defined
+ in cmd_scsi.c.
+
+ 3) mg_disk interface
+ --------------------
+
+ The mg_disk interface drivers implement the following functions:
+
+ struct mg_drv_data* mg_get_drv_data (void)
+ uint mg_disk_init (void)
+ uint mg_disk_read (u32 addr, u8 *buff, u32 len)
+ uint mg_disk_write(u32 addr, u8 *buff, u32 len)
+ uint mg_disk_write_sects(void *buff, u32 sect_num, u32 sect_cnt)
+ uint mg_disk_read_sects(void *buff, u32 sect_num, u32 sect_cnt)
+
+ The mg_get_drv_data function is to be overridden per-board, but there are no
+ board in-tree that do this.
+
+ Only one driver for this API exists, and it only supports one block device.
+ Callbacks for this device are implemented in mg_disk.c and call the mg_disk
+ API. The mg_disk_get_dev function is defined in mg_disk.c and ignores the
+ device number, always returning the same device.
+
+ 4) systemace interface
+ ----------------------
+
+ The systemace interface does not define any driver API, and has no command
+ itself. The single defined function is systemace_get_devs() from
+ systemace.c, which returns a single static structure for the only supported
+ block device. Callbacks for this device are also implemented in systemace.c.
+
+ 5) IDE interface
+ ----------------
+
+ The IDE interface drivers implement the following functions, but only if
+ CONFIG_IDE_AHB is set:
+
+ uchar ide_read_register(int dev, unsigned int port);
+ void ide_write_register(int dev, unsigned int port, unsigned char val);
+ void ide_read_data(int dev, ulong *sect_buf, int words);
+ void ide_write_data(int dev, const ulong *sect_buf, int words);
+
+ The first two functions are called from ide_inb()/ide_outb(), and will
+ default to direct memory access if CONFIG_IDE_AHB is not set, or
+ ide_inb()/ide_outb() functions will get overridden by the board altogether.
+
+ The second two functions are called from input_data()/output_data()
+ functions, and also default to direct memory access, but cannot be
+ overridden by the board.
+
+ One function shared by IDE drivers (but not defined in ide.h) is
+ int ide_preinit(void)
+ This function gets called from ide_init in cmd_ide.c if CONFIG_IDE_PREINIT
+ is defined, and will do the driver-specific initialization of the device.
+
+ Block devices are kept in ide_dev_desc[], which is filled in cmd_ide.c.
+ Callbacks of the block device are defined in cmd_ide.c, and use the
+ ide_inb()/ide_outb()/input_data()/output_data() functions mentioned above.
+ The ide_get_dev function is defined in cmd_ide.c.
+
+II) Approach
+------------
+
+ A new block controller core and an associated API will be created to mimic the
+ current SATA API, its drivers will have the following ops:
+
+ struct block_ctrl_ops {
+ int scan(instance *i);
+ int reset(instance *i, int port);
+ lbaint_t read(instance *i, int port, lbaint_t start, lbatin_t length,
+ void *buffer);
+ lbaint_t write(instance *i, int port, lbaint_t start, lbatin_t length,
+ void*buffer);
+ }
+
+ The current sata_init() function will be changed into the driver probe()
+ function. The read() and write() functions should never be called directly,
+ instead they should be called by block device driver for disks.
+
+ Other block APIs would either be transformed into this API, or be kept as
+ legacy for old drivers, or be dropped altogether.
+
+ Legacy driver APIs will each have its own driver core that will contain the
+ shared logic, which is currently located mostly in cmd_* files. Callbacks for
+ block device drivers will then probably be implemented as a part of the core
+ logic, and will use the driver ops (which will copy current state of
+ respective APIs) to do the work.
+
+ All drivers will be cleaned up, most ifdefs should be converted into
+ platform_data, to enable support for multiple devices with different settings.
+
+ A new block device core will also be created, and will keep track of all
+ block devices on all interfaces.
+
+ Current block_dev_desc structure will be changed to fit the driver model, all
+ identification and configuration will be placed in private data, and
+ a single accessor and modifier will be defined, to accommodate the need for
+ different sets of options for different interfaces, while keeping the
+ structure small. The new block device drivers will have the following ops
+ structure (lbaint_t is either 32bit or 64bit unsigned, depending on
+ CONFIG_LBA48):
+
+ struct blockdev_ops {
+ lbaint_t (*block_read)(struct instance *i, lbaint_t start, lbaint_t blkcnt,
+ void *buffer);
+ lbaint_t (*block_write)(struct instance *i, lbaint_t start, lbaint_t blkcnt,
+ void *buffer);
+ lbaint_t (*block_erase)(struct instance *i, lbaint_t start, lbaint_t blkcnt
+ );
+ int (*get_option)(struct instance *i, enum blockdev_option_code op,
+ struct option *res);
+ int (*set_option)(struct instance *i, enum blockdev_option_code op,
+ struct option *val);
+ }
+
+ struct option {
+ uint32_t flags
+ union data {
+ uint64_t data_u;
+ char* data_s;
+ void* data_p;
+ }
+ }
+
+ enum blockdev_option_code {
+ BLKD_OPT_IFTYPE=0,
+ BLKD_OPT_TYPE,
+ BLKD_OPT_BLOCKSIZE,
+ BLKD_OPT_BLOCKCOUNT,
+ BLKD_OPT_REMOVABLE,
+ BLKD_OPT_LBA48,
+ BLKD_OPT_VENDOR,
+ BLKD_OPT_PRODICT,
+ BLKD_OPT_REVISION,
+ BLKD_OPT_SCSILUN,
+ BLKD_OPT_SCSITARGET,
+ BLKD_OPT_OFFSET
+ }
+
+ Flags in option above will contain the type of returned data (which should be
+ checked against what is expected, even though the option requested should
+ specify it), and a flag to indicate whether the returned pointer needs to be
+ free()'d.
+
+ The block device core will contain the logic now located in disk/part.c and
+ related files, and will be used to forward requests to block devices. The API
+ for the block device core will copy the ops of a block device (with a string
+ identifier instead of instance pointer). This means that partitions will also
+ be handled by the block device core, and exported as block devices, making
+ them transparent to the rest of the code.
+
+ Sadly, this will change how file systems can access the devices, and thus will
+ affect a lot of places. However, these changes should be localized and easy to
+ implement.
+
+ AHCI driver will be rewritten to fit the new unified block controller API,
+ making SCSI API easy to merge with sym53c8xx, or remove it once the device
+ driver has died.
+
+ Optionally, IDE core may be changed into one driver with unified block
+ controller API, as most of it is already in one place and device drivers are
+ just sets of hooks. Additionally, mg_disk driver is unused and may be removed
+ in near future.
+
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ ahci.c
+ ------
+ SCSI API, will be rewritten for a different API.
+
+ ata_piix.c
+ ----------
+ SATA API, easy to port.
+
+ fsl_sata.c
+ ----------
+ SATA API, few CONFIG macros, easy to port.
+
+ ftide020.c
+ ----------
+ IDE API, defines CONFIG_IDE_AHB and ide_preinit hook functions.
+
+ mg_disk.c
+ ---------
+ Single driver with mg_disk API, not much to change, easy to port.
+
+ mvsata_ide.c
+ ------------
+ IDE API, only defines ide_preinit hook function.
+
+ mxc_ata.c
+ ---------
+ IDE API, only defines ide_preinit hook function.
+
+ pata_bfin.c
+ -----------
+ SATA API, easy to port.
+
+ sata_dwc.c
+ ----------
+ SATA API, easy to port.
+
+ sata_sil3114.c
+ --------------
+ SATA API, easy to port.
+
+ sata_sil.c
+ ----------
+ SATA API, easy to port.
+
+ sil680.c
+ --------
+ IDE API, only defines ide_preinit hook function.
+
+ sym53c8xx.c
+ -----------
+ SCSI API, may be merged with code from cmd_scsi.
+
+ systemace.c
+ -----------
+ Single driver with systemace API, not much to change, easy to port.
diff --git a/marvell/uboot/doc/driver-model/UDM-cores.txt b/marvell/uboot/doc/driver-model/UDM-cores.txt
new file mode 100644
index 0000000..6032333
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-cores.txt
@@ -0,0 +1,126 @@
+The U-Boot Driver Model Project
+===============================
+Driver cores API document
+=========================
+
+Pavel Herrmann <morpheus.ibis@gmail.com>
+
+1) Overview
+-----------
+ Driver cores will be used as a wrapper for devices of the same type, and as
+ an abstraction for device driver APIs. For each driver API (which roughly
+ correspond to device types), there will be one driver core. Each driver core
+ will implement three APIs - a driver API (which will be the same as API of
+ drivers the core wraps around), a core API (which will be implemented by all
+ cores) and a command API (core-specific API which will be exposed to
+ commands).
+
+ A) Command API
+ The command API will provide access to shared functionality for a specific
+ device, which is currently located mostly in commands. Commands will be
+ rewritten to be more lightweight by using this API. As this API will be
+ different for each core, it is out of scope of this document.
+
+ B) Driver API
+ The driver API will act as a wrapper around actual device drivers,
+ providing a single entrypoint for device access. All functions in this API
+ have an instance* argument (probably called "this" or "i"), which will be
+ examined by the core, and a correct function for the specified driver will
+ get called.
+
+ If the core gets called with a group instance pointer (as discussed in
+ design), it will automatically select the instance that is associated
+ with this core, and use it as target of the call. if the group contains
+ multiple instances of a single type, the caller must explicitly use an
+ accessor to select the correct instance.
+
+ This accessor will look like:
+ struct instance *get_instance_from_group(struct instance *group, int i)
+
+ When called with a non-group instance, it will simply return the instance.
+
+ C) Core API
+ The core API will be implemented by all cores, and will provide
+ functionality for getting driver instances from non-driver code. This API
+ will consist of following functions:
+
+ int get_count(struct instance *core);
+ struct instance* get_instance(struct instance *core, int index);
+ int init(struct instance *core);
+ int bind(struct instance *core, struct instance *dev, void *ops,
+ void *hint);
+ int unbind(struct instance *core, instance *dev);
+ int replace(struct instance *core, struct_instance *new_dev,
+ struct instance *old_dev);
+ int destroy(struct instance *core);
+ int reloc(struct instance *new_core, struct instance *old_core);
+
+ The 'hint' parameter of bind() serves for additional data a driver can
+ pass to the core, to help it create the correct internal state for this
+ instance. the replace() function will get called during instance
+ relocation, and will replace the old instance with the new one, keeping
+ the internal state untouched.
+
+
+2) Lifetime of a driver core
+----------------------------
+ Driver cores will be initialized at runtime, to limit memory footprint in
+ early-init stage, when we have to fit into ~1KB of memory. All active cores
+ will be stored in a tree structure (referenced as "Core tree") in global data,
+ which provides good tradeoff between size and access time.
+ Every core will have a number constant associated with it, which will be used
+ to find the instance in Core tree, and to refer to the core in all calls
+ working with the Core tree.
+ The Core Tree should be implemented using B-tree (or a similar structure)
+ to guarantee acceptable time overhead in all cases.
+
+ Code for working with the core (i2c in this example) follows:
+
+ core_init(CORE_I2C);
+ This will check whether we already have a i2c core, and if not it creates
+ a new instance and adds it into the Core tree. This will not be exported,
+ all code should depend on get_core_instance to init the core when
+ necessary.
+
+ get_core_instance(CORE_I2C);
+ This is an accessor into the Core tree, which will return the instance
+ of i2c core, creating it if necessary
+
+ core_bind(CORE_I2C, instance, driver_ops);
+ This will get called in bind() function of a driver, and will add the
+ instance into cores internal list of devices. If the core is not found, it
+ will get created.
+
+ driver_activate(instance *inst);
+ This call will recursively activate all devices necessary for using the
+ specified device. the code could be simplified as:
+ {
+ if (is_activated(inst))
+ return;
+ driver_activate(inst->bus);
+ get_driver(inst)->probe(inst);
+ }
+
+ The case with multiple parents will need to be handled here as well.
+ get_driver is an accessor to available drivers, which will get struct
+ driver based on a name in the instance.
+
+ i2c_write(instance *inst, ...);
+ An actual call to some method of the driver. This code will look like:
+ {
+ driver_activate(inst);
+ struct instance *core = get_core_instance(CORE_I2C);
+ device_ops = get_ops(inst);
+ device_ops->write(...);
+ }
+
+ get_ops will not be an exported function, it will be internal and specific
+ to the core, as it needs to know how are the ops stored, and what type
+ they are.
+
+ Please note that above examples represent the algorithm, not the actual code,
+ as they are missing checks for validity of return values.
+
+ core_init() function will get called the first time the core is requested,
+ either by core_link() or core_get_instance(). This way, the cores will get
+ created only when they are necessary, which will reduce our memory footprint.
diff --git a/marvell/uboot/doc/driver-model/UDM-design.txt b/marvell/uboot/doc/driver-model/UDM-design.txt
new file mode 100644
index 0000000..9f03bba
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-design.txt
@@ -0,0 +1,315 @@
+The U-Boot Driver Model Project
+===============================
+Design document
+===============
+Marek Vasut <marek.vasut@gmail.com>
+Pavel Herrmann <morpheus.ibis@gmail.com>
+2012-05-17
+
+I) The modular concept
+----------------------
+
+The driver core design is done with modularity in mind. The long-term plan is to
+extend this modularity to allow loading not only drivers, but various other
+objects into U-Boot at runtime -- like commands, support for other boards etc.
+
+II) Driver core initialization stages
+-------------------------------------
+
+The drivers have to be initialized in two stages, since the U-Boot bootloader
+runs in two stages itself. The first stage is the one which is executed before
+the bootloader itself is relocated. The second stage then happens after
+relocation.
+
+ 1) First stage
+ --------------
+
+ The first stage runs after the bootloader did very basic hardware init. This
+ means the stack pointer was configured, caches disabled and that's about it.
+ The problem with this part is the memory management isn't running at all. To
+ make things even worse, at this point, the RAM is still likely uninitialized
+ and therefore unavailable.
+
+ 2) Second stage
+ ---------------
+
+ At this stage, the bootloader has initialized RAM and is running from it's
+ final location. Dynamic memory allocations are working at this point. Most of
+ the driver initialization is executed here.
+
+III) The drivers
+----------------
+
+ 1) The structure of a driver
+ ----------------------------
+
+ The driver will contain a structure located in a separate section, which
+ will allow linker to create a list of compiled-in drivers at compile time.
+ Let's call this list "driver_list".
+
+ struct driver __attribute__((section(driver_list))) {
+ /* The name of the driver */
+ char name[STATIC_CONFIG_DRIVER_NAME_LENGTH];
+
+ /*
+ * This function should connect this driver with cores it depends on and
+ * with other drivers, likely bus drivers
+ */
+ int (*bind)(struct instance *i);
+
+ /* This function actually initializes the hardware. */
+ int (*probe)(struct instance *i);
+
+ /*
+ * The function of the driver called when U-Boot finished relocation.
+ * This is particularly important to eg. move pointers to DMA buffers
+ * and such from the location before relocation to their final location.
+ */
+ int (*reloc)(struct instance *i);
+
+ /*
+ * This is called when the driver is shuting down, to deinitialize the
+ * hardware.
+ */
+ int (*remove)(struct instance *i);
+
+ /* This is called to remove the driver from the driver tree */
+ int (*unbind)(struct instance *i);
+
+ /* This is a list of cores this driver depends on */
+ struct driver *cores[];
+ };
+
+ The cores[] array in here is very important. It allows u-boot to figure out,
+ in compile-time, which possible cores can be activated at runtime. Therefore
+ if there are cores that won't be ever activated, GCC LTO might remove them
+ from the final binary. Actually, this information might be used to drive build
+ of the cores.
+
+ FIXME: Should *cores[] be really struct driver, pointing to drivers that
+ represent the cores? Shouldn't it be core instance pointer?
+
+ 2) Instantiation of a driver
+ ----------------------------
+
+ The driver is instantiated by calling:
+
+ driver_bind(struct instance *bus, const struct driver_info *di)
+
+ The "struct instance *bus" is a pointer to a bus with which this driver should
+ be registered with. The "root" bus pointer is supplied to the board init
+ functions.
+
+ FIXME: We need some functions that will return list of busses of certain type
+ registered with the system so the user can find proper instance even if
+ he has no bus pointer (this will come handy if the user isn't
+ registering the driver from board init function, but somewhere else).
+
+ The "const struct driver_info *di" pointer points to a structure defining the
+ driver to be registered. The structure is defined as follows:
+
+ struct driver_info {
+ char name[STATIC_CONFIG_DRIVER_NAME_LENGTH];
+ void *platform_data;
+ }
+
+ The instantiation of a driver by calling driver_bind() creates an instance
+ of the driver by allocating "struct driver_instance". Note that only struct
+ instance is passed to the driver. The wrapping struct driver_instance is there
+ for purposes of the driver core:
+
+ struct driver_instance {
+ uint32_t flags;
+ struct instance i;
+ };
+
+ struct instance {
+ /* Pointer to a driver information passed by driver_register() */
+ const struct driver_info *info;
+ /* Pointer to a bus this driver is bound with */
+ struct instance *bus;
+ /* Pointer to this driver's own private data */
+ void *private_data;
+ /* Pointer to the first block of successor nodes (optional) */
+ struct successor_block *succ;
+ }
+
+ The instantiation of a driver does not mean the hardware is initialized. The
+ driver_bind() call only creates the instance of the driver, fills in the "bus"
+ pointer and calls the drivers' .bind() function. The .bind() function of the
+ driver should hook the driver with the remaining cores and/or drivers it
+ depends on.
+
+ It's important to note here, that in case the driver instance has multiple
+ parents, such parent can be connected with this instance by calling:
+
+ driver_link(struct instance *parent, struct instance *dev);
+
+ This will connect the other parent driver with the newly instantiated driver.
+ Note that this must be called after driver_bind() and before driver_acticate()
+ (driver_activate() will be explained below). To allow struct instance to have
+ multiple parent pointer, the struct instance *bus will utilize it's last bit
+ to indicate if this is a pointer to struct instance or to an array if
+ instances, struct successor block. The approach is similar as the approach to
+ *succ in struct instance, described in the following paragraph.
+
+ The last pointer of the struct instance, the pointer to successor nodes, is
+ used only in case of a bus driver. Otherwise the pointer contains NULL value.
+ The last bit of this field indicates if this is a bus having a single child
+ node (so the last bit is 0) or if this bus has multiple child nodes (the last
+ bit is 1). In the former case, the driver core should clear the last bit and
+ this pointer points directly to the child node. In the later case of a bus
+ driver, the pointer points to an instance of structure:
+
+ struct successor_block {
+ /* Array of pointers to instances of devices attached to this bus */
+ struct instance *dev[BLOCKING_FACTOR];
+ /* Pointer to next block of successors */
+ struct successor_block *next;
+ }
+
+ Some of the *dev[] array members might be NULL in case there are no more
+ devices attached. The *next is NULL in case the list of attached devices
+ doesn't continue anymore. The BLOCKING_FACTOR is used to allocate multiple
+ slots for successor devices at once to avoid fragmentation of memory.
+
+ 3) The bind() function of a driver
+ ----------------------------------
+
+ The bind function of a driver connects the driver with various cores the
+ driver provides functions for. The driver model related part will look like
+ the following example for a bus driver:
+
+ int driver_bind(struct instance *in)
+ {
+ ...
+ core_bind(&core_i2c_static_instance, in, i2c_bus_funcs);
+ ...
+ }
+
+ FIXME: What if we need to run-time determine, depending on some hardware
+ register, what kind of i2c_bus_funcs to pass?
+
+ This makes the i2c core aware of a new bus. The i2c_bus_funcs is a constant
+ structure of functions any i2c bus driver must provide to work. This will
+ allow the i2c command operate with the bus. The core_i2c_static_instance is
+ the pointer to the instance of a core this driver provides function to.
+
+ FIXME: Maybe replace "core-i2c" with CORE_I2C global pointer to an instance of
+ the core?
+
+ 4) The instantiation of a core driver
+ -------------------------------------
+
+ The core driver is special in the way that it's single-instance driver. It is
+ always present in the system, though it might not be activated. The fact that
+ it's single instance allows it to be instantiated at compile time.
+
+ Therefore, all possible structures of this driver can be in read-only memory,
+ especially struct driver and struct driver_instance. But the successor list,
+ which needs special treatment.
+
+ To solve the problem with a successor list and the core driver flags, a new
+ entry in struct gd (global data) will be introduced. This entry will point to
+ runtime allocated array of struct driver_instance. It will be possible to
+ allocate the exact amount of struct driver_instance necessary, as the number
+ of cores that might be activated will be known at compile time. The cores will
+ then behave like any usual driver.
+
+ Pointers to the struct instance of cores can be computed at compile time,
+ therefore allowing the resulting u-boot binary to save some overhead.
+
+ 5) The probe() function of a driver
+ -----------------------------------
+
+ The probe function of a driver allocates necessary resources and does required
+ initialization of the hardware itself. This is usually called only when the
+ driver is needed, as a part of the defered probe mechanism.
+
+ The driver core should implement a function called
+
+ int driver_activate(struct instance *in);
+
+ which should call the .probe() function of the driver and then configure the
+ state of the driver instance to "ACTIVATED". This state of a driver instance
+ should be stored in a wrap-around structure for the structure instance, the
+ struct driver_instance.
+
+ 6) The command side interface to a driver
+ -----------------------------------------
+
+ The U-Boot command shall communicate only with the specific driver core. The
+ driver core in turn exports necessary API towards the command.
+
+ 7) Demonstration imaginary board
+ --------------------------------
+
+ Consider the following computer:
+
+ *
+ |
+ +-- System power management logic
+ |
+ +-- CPU clock controlling logc
+ |
+ +-- NAND controller
+ | |
+ | +-- NAND flash chip
+ |
+ +-- 128MB of DDR DRAM
+ |
+ +-- I2C bus #0
+ | |
+ | +-- RTC
+ | |
+ | +-- EEPROM #0
+ | |
+ | +-- EEPROM #1
+ |
+ +-- USB host-only IP core
+ | |
+ | +-- USB storage device
+ |
+ +-- USB OTG-capable IP core
+ | |
+ | +-- connection to the host PC
+ |
+ +-- GPIO
+ | |
+ | +-- User LED #0
+ | |
+ | +-- User LED #1
+ |
+ +-- UART0
+ |
+ +-- UART1
+ |
+ +-- Ethernet controller #0
+ |
+ +-- Ethernet controller #1
+ |
+ +-- Audio codec
+ |
+ +-- PCI bridge
+ | |
+ | +-- Ethernet controller #2
+ | |
+ | +-- SPI host card
+ | | |
+ | | +-- Audio amplifier (must be operational before codec)
+ | |
+ | +-- GPIO host card
+ | |
+ | +-- User LED #2
+ |
+ +-- LCD controller
+ |
+ +-- PWM controller (must be enabled after LCD controller)
+ |
+ +-- SPI host controller
+ | |
+ | +-- SD/MMC connected via SPI
+ | |
+ | +-- SPI flash
+ |
+ +-- CPLD/FPGA with stored configuration of the board
diff --git a/marvell/uboot/doc/driver-model/UDM-fpga.txt b/marvell/uboot/doc/driver-model/UDM-fpga.txt
new file mode 100644
index 0000000..4f9df94
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-fpga.txt
@@ -0,0 +1,115 @@
+The U-Boot Driver Model Project
+===============================
+I/O system analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-21
+
+I) Overview
+-----------
+
+The current FPGA implementation is handled by command "fpga". This command in
+turn calls the following functions:
+
+fpga_info()
+fpga_load()
+fpga_dump()
+
+These functions are implemented by what appears to be FPGA multiplexer, located
+in drivers/fpga/fpga.c . This code determines which device to operate with
+depending on the device ID.
+
+The fpga_info() function is multiplexer of the functions providing information
+about the particular FPGA device. These functions are implemented in the drivers
+for the particular FPGA device:
+
+xilinx_info()
+altera_info()
+lattice_info()
+
+Similar approach is used for fpga_load(), which multiplexes "xilinx_load()",
+"altera_load()" and "lattice_load()" and is used to load firmware into the FPGA
+device.
+
+The fpga_dump() function, which prints the contents of the FPGA device, is no
+different either, by multiplexing "xilinx_dump()", "altera_dump()" and
+"lattice_dump()" functions.
+
+Finally, each new FPGA device is registered by calling "fpga_add()" function.
+This function takes two arguments, the second one being particularly important,
+because it's basically what will become platform_data. Currently, it's data that
+are passed to the driver from the board/platform code.
+
+II) Approach
+------------
+
+The path to conversion of the FPGA subsystem will be very straightforward, since
+the FPGA subsystem is already quite dynamic. Multiple things will need to be
+modified though.
+
+First is the registration of the new FPGA device towards the FPGA core. This
+will be achieved by calling:
+
+ fpga_device_register(struct instance *i, const struct fpga_ops *ops);
+
+The particularly interesting part is the struct fpga_ops, which contains
+operations supported by the FPGA device. These are basically the already used
+calls in the current implementation:
+
+struct fpga_ops {
+ int info(struct instance *i);
+ int load(struct instance *i, const char *buf, size_t size);
+ int dump(struct instance *i, const char *buf, size_t size);
+}
+
+The other piece that'll have to be modified is how the devices are tracked.
+It'll be necessary to introduce a linked list of devices within the FPGA core
+instead of tracking them by ID number.
+
+Next, the "Xilinx_desc", "Lattice_desc" and "Altera_desc" structures will have
+to be moved to driver's private_data. Finally, structures passed from the board
+and/or platform files, like "Xilinx_Virtex2_Slave_SelectMap_fns" would be passed
+via platform_data to the driver.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ 1) Altera driver
+ ----------------
+ The driver is realized using the following files:
+
+ drivers/fpga/altera.c
+ drivers/fpga/ACEX1K.c
+ drivers/fpga/cyclon2.c
+ drivers/fpga/stratixII.c
+
+ All of the sub-drivers implement basically the same info-load-dump interface
+ and there's no expected problem during the conversion. The driver itself will
+ be realised by altera.c and all the sub-drivers will be linked in. The
+ distinction will be done by passing different platform data.
+
+ 2) Lattice driver
+ -----------------
+ The driver is realized using the following files:
+
+ drivers/fpga/lattice.c
+ drivers/fpga/ivm_core.c
+
+ This driver also implements the standard interface, but to realise the
+ operations with the FPGA device, uses functions from "ivm_core.c" file. This
+ file implements the main communications logic and has to be linked in together
+ with "lattice.c". No problem converting is expected here.
+
+ 3) Xilinx driver
+ ----------------
+ The driver is realized using the following files:
+
+ drivers/fpga/xilinx.c
+ drivers/fpga/spartan2.c
+ drivers/fpga/spartan3.c
+ drivers/fpga/virtex2.c
+
+ This set of sub-drivers is special by defining a big set of macros in
+ "include/spartan3.h" and similar files. These macros would need to be either
+ rewritten or replaced. Otherwise, there are no problems expected during the
+ conversion process.
diff --git a/marvell/uboot/doc/driver-model/UDM-gpio.txt b/marvell/uboot/doc/driver-model/UDM-gpio.txt
new file mode 100644
index 0000000..585d458
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-gpio.txt
@@ -0,0 +1,106 @@
+The U-Boot Driver Model Project
+===============================
+GPIO analysis
+=============
+Viktor Krivak <viktor.krivak@gmail.com>
+2012-02-24
+
+I) Overview
+-----------
+
+ At this moment U-Boot provides standard API that consists of 7 functions.
+
+ int gpio_request(unsigned gpio, const char *label)
+ int gpio_free(unsigned gpio)
+ int gpio_direction_input(unsigned gpio)
+ int gpio_direction_output(unsigned gpio, int value)
+ int gpio_get_value(unsigned gpio)
+ void gpio_set_value(unsigned gpio, int value)
+
+ Methods "gpio_request()" and "gpio_free()" are used for claiming and releasing
+ GPIOs. First one should check if the desired pin exists and if the pin wasn't
+ requested already elsewhere. The method also has a label argument that can be
+ used for debug purposes. The label argument should be copied into the internal
+ memory, but only if the DEBUG macro is set. The "gpio_free()" is the exact
+ opposite. It releases the particular pin. Other methods are used for setting
+ input or output direction and obtaining or setting values of the pins.
+
+II) Approach
+------------
+
+ 1) Request and free GPIO
+ ------------------------
+
+ The "gpio_request()" implementation is basically the same for all boards.
+ The function checks if the particular GPIO is correct and checks if the
+ GPIO pin is still free. If the conditions are met, the method marks the
+ GPIO claimed in it's internal structure. If macro DEBUG is defined, the
+ function also copies the label argument to the structure. If the pin is
+ already locked, the function returns -1 and if DEBUG is defined, certain
+ debug output is generated, including the contents of the label argument.
+ The "gpio_free()" function releases the lock and eventually deallocates
+ data used by the copied label argument.
+
+ 2) Internal data
+ ----------------
+
+ Internal data are driver specific. They have to contain some mechanism to
+ realise the locking though. This can be done for example using a bit field.
+
+ 3) Operations provided by the driver
+ ------------------------------------
+
+ The driver operations basically meet API that is already defined and used.
+ Except for "gpio_request()" and "gpio_free()", all methods can be converted in
+ a simple manner. The driver provides the following structure:
+
+ struct gpio_driver_ops {
+ int (*gpio_request)(struct instance *i, unsigned gpio,
+ const char *label);
+ int (*gpio_free)(struct instance *i, unsigned gpio);
+ int (*gpio_direction_input)(struct instance *i, unsigned gpio);
+ int (*gpio_direction_output)(struct instance *i, unsigned gpio,
+ int value);
+ int (*gpio_get_value)(struct instance *i, unsigned gpio);
+ void (*gpio_set_value)(struct instance *i, unsigned gpio, int value);
+ }
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ altera_pio.c
+ ------------
+ Meets standard API. Implements gpio_request() properly. Simple conversion
+ possible.
+
+ at91_gpio.c
+ -----------
+ Don't meet standard API. Need some other methods to implement.
+
+ da8xx_gpio.c
+ ------------
+ Meets standard API. Implements gpio_request() properly. Simple conversion
+ possible.
+
+ kw_gpio.c
+ ---------
+ Doesn't meet standard API. Needs some other methods to implement and move some
+ methods to another file.
+
+ mpc83xx_gpio.c
+ --------------
+ Meets standard API. Doesn't implement gpio_request() properly (only checks
+ if the pin is valid). Simple conversion possible.
+
+ mvgpio.c
+ --------
+ Meets standard API. Doesn't implement gpio_request() properly (only checks
+ if the pin is valid). Simple conversion possible.
+
+ mvgpio.h
+ --------
+ Wrong placement. Will be moved to another location.
+
+ mvmfp.c
+ -------
+ Wrong placement. Will be moved to another location.
diff --git a/marvell/uboot/doc/driver-model/UDM-hwmon.txt b/marvell/uboot/doc/driver-model/UDM-hwmon.txt
new file mode 100644
index 0000000..03a96a0
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-hwmon.txt
@@ -0,0 +1,118 @@
+The U-Boot Driver Model Project
+===============================
+Hwmon device subsystem analysis
+===============================
+
+Tomas Hlavacek <tmshlvck@gmail.com>
+2012-03-02
+
+I) Overview
+-----------
+
+U-Boot currently implements one API for HW monitoring devices. The
+interface is defined in include/dtt.h and comprises of functions:
+
+ void dtt_init(void);
+ int dtt_init_one(int);
+ int dtt_read(int sensor, int reg);
+ int dtt_write(int sensor, int reg, int val);
+ int dtt_get_temp(int sensor);
+
+The functions are implemented by a proper device driver in drivers/hwmon
+directory and the driver to be compiled in is selected in a Makefile.
+Drivers are mutually exclusive.
+
+Drivers depends on I2O code and naturally on board specific data. There are
+few ad-hoc constants put in dtt.h file and driver headers and code. This
+has to be consolidated into board specific data or driver headers if those
+constants makes sense globally.
+
+
+II) Approach
+------------
+
+ 1) New API
+ ----------
+ In the UDM each hwmon driver would register itself by a function
+
+ int hwmon_device_register(struct instance *i,
+ struct hwmon_device_ops *o);
+
+ The structure being defined as follows:
+
+ struct hwmon_device_ops {
+ int (*read)(struct instance *i, int sensor, int reg);
+ int (*write)(struct instance *i, int sensor, int reg,
+ int val);
+ int (*get_temp)(struct instance *i, int sensor);
+ };
+
+
+ 2) Conversion thougths
+ ----------------------
+ U-Boot hwmon drivers exports virtually the same functions (with exceptions)
+ and we are considering low number of drivers and code anyway. The interface
+ is already similar and unified by the interface defined in dtt.h.
+ Current initialization functions dtt_init() and dtt_init_one() will be
+ converted into probe() and hwmon_device_register(), so the funcionality will
+ be kept in more proper places. Besides implementing core registration and
+ initialization we need to do code cleanup, especially separate
+ driver-specific and HW specific constants.
+
+ 3) Special consideration due to early initialization
+ ----------------------------------------------------
+ The dtt_init() function call is used during early initialization in
+ board/gdsys/405ex/io64.c for starting up fans. The dtt code is perfectly
+ usable in the early stage because it uses only local variables and no heap
+ memory is required at this level. However the underlying code of I2C has to
+ keep the same properties with regard to possibility of running in early
+ initialization stage.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ drivers/hwmon/lm81.c
+ --------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/ds1722.c
+ ----------------------
+ The driver is not standard dtt, but interface is similar to dtt.
+ The interface has to be changed in order to comply to above mentioned
+ specification.
+
+
+ drivers/hwmon/ds1775.c
+ ----------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/lm73.c
+ --------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/lm63.c
+ --------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/adt7460.c
+ -----------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/lm75.c
+ --------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/ds1621.c
+ ----------------------
+ The driver is standard dtt. Simple conversion is possible.
+
+
+ drivers/hwmon/adm1021.c
+ -----------------------
+ The driver is standard dtt. Simple conversion is possible.
diff --git a/marvell/uboot/doc/driver-model/UDM-keyboard.txt b/marvell/uboot/doc/driver-model/UDM-keyboard.txt
new file mode 100644
index 0000000..5babfc5
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-keyboard.txt
@@ -0,0 +1,47 @@
+The U-Boot Driver Model Project
+===============================
+Keyboard input analysis
+=======================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-20
+
+I) Overview
+-----------
+
+The keyboard drivers are most often registered with STDIO subsystem. There are
+components of the keyboard drivers though, which operate in severe ad-hoc
+manner, often being related to interrupt-driven keypress reception. This
+components will require the most sanitization of all parts of keyboard input
+subsystem.
+
+Otherwise, the keyboard is no different from other standard input but with the
+necessity to decode scancodes. These are decoded using tables provided by
+keyboard drivers. These tables are often driver specific.
+
+II) Approach
+------------
+
+The most problematic part is the interrupt driven keypress reception. For this,
+the buffers that are currently shared throughout the whole U-Boot would need to
+be converted into driver's private data.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ board/mpl/common/kbd.c
+ ----------------------
+ This driver is a classic STDIO driver, no problem with conversion is expected.
+ Only necessary change will be to move this driver to a proper location.
+
+ board/rbc823/kbd.c
+ ------------------
+ This driver is a classic STDIO driver, no problem with conversion is expected.
+ Only necessary change will be to move this driver to a proper location.
+
+ drivers/input/keyboard.c
+ ------------------------
+ This driver is special in many ways. Firstly because this is a universal stub
+ driver for converting scancodes from i8042 and the likes. Secondly because the
+ buffer is filled by various other ad-hoc implementations of keyboard input by
+ using this buffer as an extern. This will need to be fixed by allowing drivers
+ to pass certain routines to this driver via platform data.
diff --git a/marvell/uboot/doc/driver-model/UDM-mmc.txt b/marvell/uboot/doc/driver-model/UDM-mmc.txt
new file mode 100644
index 0000000..97f83a7
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-mmc.txt
@@ -0,0 +1,319 @@
+The U-Boot Driver Model Project
+===============================
+MMC system analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-25
+
+I) Overview
+-----------
+
+The MMC subsystem is already quite dynamic in it's nature. It's only necessary
+to flip the subsystem to properly defined API.
+
+The probing process of MMC drivers start by calling "mmc_initialize()",
+implemented by MMC framework, from the architecture initialization file. The
+"mmc_initialize()" function in turn calls "board_mmc_init()" function and if
+this doesn't succeed, "cpu_mmc_init()" function is called. It is important to
+note that both of the "*_mmc_init()" functions have weak aliases to functions
+which automatically fail.
+
+Both of the "*_mmc_init()" functions though serve only one purpose. To call
+driver specific probe function, which in turn actually registers the driver with
+MMC subsystem. Each of the driver specific probe functions is currently done in
+very ad-hoc manner.
+
+The registration with the MMC subsystem is done by calling "mmc_register()",
+whose argument is a runtime configured structure of information about the MMC
+driver. Currently, the information structure is intermixed with driver's internal
+data. The description of the structure follows:
+
+struct mmc {
+ /*
+ * API: Allows this driver to be a member of the linked list of all MMC drivers
+ * registered with MMC subsystem
+ */
+ struct list_head link;
+
+ /* DRIVER: Name of the registered driver */
+ char name[32];
+
+ /* DRIVER: Driver's private data */
+ void *priv;
+
+ /* DRIVER: Voltages the host bus can provide */
+ uint voltages;
+
+ /* API: Version of the card */
+ uint version;
+
+ /* API: Test if the driver was already initialized */
+ uint has_init;
+
+ /* DRIVER: Minimum frequency the host bus can provide */
+ uint f_min;
+
+ /* DRIVER: Maximum frequency the host bus can provide */
+ uint f_max;
+
+ /* API: Is the card SDHC */
+ int high_capacity;
+
+ /* API: Actual width of the bus used by the current card */
+ uint bus_width;
+
+ /*
+ * DRIVER: Clock frequency to be configured on the host bus, this is read-only
+ * for the driver.
+ */
+ uint clock;
+
+ /* API: Capabilities of the card */
+ uint card_caps;
+
+ /* DRIVER: MMC bus capabilities */
+ uint host_caps;
+
+ /* API: Configuration and ID data retrieved from the card */
+ uint ocr;
+ uint scr[2];
+ uint csd[4];
+ uint cid[4];
+ ushort rca;
+
+ /* API: Partition configuration */
+ char part_config;
+
+ /* API: Number of partitions */
+ char part_num;
+
+ /* API: Transmission speed */
+ uint tran_speed;
+
+ /* API: Read block length */
+ uint read_bl_len;
+
+ /* API: Write block length */
+ uint write_bl_len;
+
+ /* API: Erase group size */
+ uint erase_grp_size;
+
+ /* API: Capacity of the card */
+ u64 capacity;
+
+ /* API: Descriptor of this block device */
+ block_dev_desc_t block_dev;
+
+ /* DRIVER: Function used to submit command to the card */
+ int (*send_cmd)(struct mmc *mmc,
+ struct mmc_cmd *cmd, struct mmc_data *data);
+
+ /* DRIVER: Function used to configure the host */
+ void (*set_ios)(struct mmc *mmc);
+
+ /* DRIVER: Function used to initialize the host */
+ int (*init)(struct mmc *mmc);
+
+ /* DRIVER: Function used to report the status of Card Detect pin */
+ int (*getcd)(struct mmc *mmc);
+
+ /*
+ * DRIVER: Maximum amount of blocks sent during multiblock xfer,
+ * set to 0 to autodetect.
+ */
+ uint b_max;
+};
+
+The API above is the new API used by most of the drivers. There're still drivers
+in the tree that use old, legacy API though.
+
+2) Approach
+-----------
+
+To convert the MMC subsystem to a proper driver model, the "struct mmc"
+structure will have to be properly split in the first place. The result will
+consist of multiple parts, first will be the structure defining operations
+provided by the MMC driver:
+
+struct mmc_driver_ops {
+ /* Function used to submit command to the card */
+ int (*send_cmd)(struct mmc *mmc,
+ struct mmc_cmd *cmd, struct mmc_data *data);
+ /* DRIVER: Function used to configure the host */
+ void (*set_ios)(struct mmc *mmc);
+ /* Function used to initialize the host */
+ int (*init)(struct mmc *mmc);
+ /* Function used to report the status of Card Detect pin */
+ int (*getcd)(struct mmc *mmc);
+}
+
+The second part will define the parameters of the MMC driver:
+
+struct mmc_driver_params {
+ /* Voltages the host bus can provide */
+ uint32_t voltages;
+ /* Minimum frequency the host bus can provide */
+ uint32_t f_min;
+ /* Maximum frequency the host bus can provide */
+ uint32_t f_max;
+ /* MMC bus capabilities */
+ uint32_t host_caps;
+ /*
+ * Maximum amount of blocks sent during multiblock xfer,
+ * set to 0 to autodetect.
+ */
+ uint32_t b_max;
+}
+
+And finally, the internal per-card data of the MMC subsystem core:
+
+struct mmc_card_props {
+ /* Version of the card */
+ uint32_t version;
+ /* Test if the driver was already initializes */
+ bool has_init;
+ /* Is the card SDHC */
+ bool high_capacity;
+ /* Actual width of the bus used by the current card */
+ uint8_t bus_width;
+ /* Capabilities of the card */
+ uint32_t card_caps;
+ /* Configuration and ID data retrieved from the card */
+ uint32_t ocr;
+ uint32_t scr[2];
+ uint32_t csd[4];
+ uint32_t cid[4];
+ uint16_t rca;
+ /* Partition configuration */
+ uint8_t part_config;
+ /* Number of partitions */
+ uint8_t part_num;
+ /* Transmission speed */
+ uint32_t tran_speed;
+ /* Read block length */
+ uint32_t read_bl_len;
+ /* Write block length */
+ uint32_t write_bl_len;
+ /* Erase group size */
+ uint32_t erase_grp_size;
+ /* Capacity of the card */
+ uint64_t capacity;
+ /* Descriptor of this block device */
+ block_dev_desc_t block_dev;
+}
+
+The probe() function will then register the MMC driver by calling:
+
+ mmc_device_register(struct instance *i, struct mmc_driver_ops *o,
+ struct mmc_driver_params *p);
+
+The struct mmc_driver_params will have to be dynamic in some cases, but the
+driver shouldn't modify it's contents elsewhere than in probe() call.
+
+Next, since the MMC drivers will now be consistently registered into the driver
+tree from board file, the functions "board_mmc_init()" and "cpu_mmc_init()" will
+disappear altogether.
+
+As for the legacy drivers, these will either be converted or removed altogether.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ arm_pl180_mmci.c
+ ----------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ atmel_mci.c
+ -----------
+ This driver uses the legacy API and should be removed unless converted. It is
+ probably possbible to replace this driver with gen_atmel_mci.c . No conversion
+ will be done on this driver.
+
+ bfin_sdh.c
+ ----------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ davinci_mmc.c
+ -------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ fsl_esdhc.c
+ -----------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple, unless some problem appears due to the FDT
+ component of the driver.
+
+ ftsdc010_esdhc.c
+ ----------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ gen_atmel_mci.c
+ ---------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ mmc_spi.c
+ ---------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ mv_sdhci.c
+ ----------
+ This is a component of the SDHCI support, allowing it to run on Marvell
+ Kirkwood chip. It is probable the SDHCI support will have to be modified to
+ allow calling functions from this file based on information passed via
+ platform_data.
+
+ mxcmmc.c
+ --------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ mxsmmc.c
+ --------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ omap_hsmmc.c
+ ------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ pxa_mmc.c
+ ---------
+ This driver uses the legacy API and is written in a severely ad-hoc manner.
+ This driver will be removed in favor of pxa_mmc_gen.c, which is proved to work
+ better and is already well tested. No conversion will be done on this driver
+ anymore.
+
+ pxa_mmc_gen.c
+ -------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ s5p_mmc.c
+ ---------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ sdhci.c
+ -------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple, though it'd be necessary to modify this driver
+ to also support the Kirkwood series and probably also Tegra series of CPUs.
+ See the respective parts of this section for details.
+
+ sh_mmcif.c
+ ----------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
+
+ tegra2_mmc.c
+ ------------
+ Follows the new API and also has a good encapsulation of the whole driver. The
+ conversion here will be simple.
diff --git a/marvell/uboot/doc/driver-model/UDM-net.txt b/marvell/uboot/doc/driver-model/UDM-net.txt
new file mode 100644
index 0000000..097ed69
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-net.txt
@@ -0,0 +1,428 @@
+The U-Boot Driver Model Project
+===============================
+Net system analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-03-03
+
+I) Overview
+-----------
+
+The networking subsystem already supports multiple devices. Therefore the
+conversion shall not be very hard.
+
+The network subsystem is operated from net/eth.c, which tracks all registered
+ethernet interfaces and calls their particular functions registered via
+eth_register().
+
+The eth_register() is called from the network driver initialization function,
+which in turn is called most often either from "board_net_init()" or
+"cpu_net_init()". This function has one important argument, which is the
+"struct eth_device", defined at include/net.h:
+
+struct eth_device {
+ /* DRIVER: Name of the device */
+ char name[NAMESIZE];
+ /* DRIVER: MAC address */
+ unsigned char enetaddr[6];
+ /* DRIVER: Register base address */
+ int iobase;
+ /* CORE: state of the device */
+ int state;
+
+ /* DRIVER: Device initialization function */
+ int (*init) (struct eth_device*, bd_t*);
+ /* DRIVER: Function for sending packets */
+ int (*send) (struct eth_device*, volatile void* packet, int length);
+ /* DRIVER: Function for receiving packets */
+ int (*recv) (struct eth_device*);
+ /* DRIVER: Function to cease operation of the device */
+ void (*halt) (struct eth_device*);
+ /* DRIVER: Function to send multicast packet (OPTIONAL) */
+ int (*mcast) (struct eth_device*, u32 ip, u8 set);
+ /* DRIVER: Function to change ethernet MAC address */
+ int (*write_hwaddr) (struct eth_device*);
+ /* CORE: Next device in the linked list of devices managed by net core */
+ struct eth_device *next;
+ /* CORE: Device index */
+ int index;
+ /* DRIVER: Driver's private data */
+ void *priv;
+};
+
+This structure defines the particular driver, though also contains elements that
+should not be exposed to the driver, like core state.
+
+Small, but important part of the networking subsystem is the PHY management
+layer, whose drivers are contained in drivers/net/phy. These drivers register in
+a very similar manner to network drivers, by calling "phy_register()" with the
+argument of "struct phy_driver":
+
+struct phy_driver {
+ /* DRIVER: Name of the PHY driver */
+ char *name;
+ /* DRIVER: UID of the PHY driver */
+ unsigned int uid;
+ /* DRIVER: Mask for UID of the PHY driver */
+ unsigned int mask;
+ /* DRIVER: MMDS of the PHY driver */
+ unsigned int mmds;
+ /* DRIVER: Features the PHY driver supports */
+ u32 features;
+ /* DRIVER: Initialize the PHY hardware */
+ int (*probe)(struct phy_device *phydev);
+ /* DRIVER: Reconfigure the PHY hardware */
+ int (*config)(struct phy_device *phydev);
+ /* DRIVER: Turn on the PHY hardware, allow it to send/receive */
+ int (*startup)(struct phy_device *phydev);
+ /* DRIVER: Turn off the PHY hardware */
+ int (*shutdown)(struct phy_device *phydev);
+ /* CORE: Allows this driver to be part of list of drivers */
+ struct list_head list;
+};
+
+II) Approach
+------------
+
+To convert the elements of network subsystem to proper driver model method, the
+"struct eth_device" will have to be split into multiple components. The first
+will be a structure defining the driver operations:
+
+struct eth_driver_ops {
+ int (*init)(struct instance*, bd_t*);
+ int (*send)(struct instance*, void *packet, int length);
+ int (*recv)(struct instance*);
+ void (*halt)(struct instance*);
+ int (*mcast)(struct instance*, u32 ip, u8 set);
+ int (*write_hwaddr)(struct instance*);
+};
+
+Next, there'll be platform data which will be per-driver and will replace the
+"priv" part of "struct eth_device". Last part will be the per-device core state.
+
+With regards to the PHY part of the API, the "struct phy_driver" is almost ready
+to be used with the new driver model approach. The only change will be the
+replacement of per-driver initialization functions and removal of
+"phy_register()" function in favor or driver model approach.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ drivers/net/4xx_enet.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/altera_tse.c
+ ------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/armada100_fec.c
+ ---------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/at91_emac.c
+ -----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ax88180.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ax88796.c
+ ---------------------
+
+ This file contains a components of the NE2000 driver, implementing only
+ different parts on the NE2000 clone AX88796. This being no standalone driver,
+ no conversion will be done here.
+
+ drivers/net/bfin_mac.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/calxedaxgmac.c
+ --------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/cs8900.c
+ --------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/davinci_emac.c
+ --------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/dc2114x.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/designware.c
+ ------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/dm9000x.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/dnet.c
+ ------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/e1000.c
+ -------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/e1000_spi.c
+ -----------------------
+
+ Driver for the SPI bus integrated on the Intel E1000. This is not part of the
+ network stack.
+
+ drivers/net/eepro100.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/enc28j60.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ep93xx_eth.c
+ ------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ethoc.c
+ -------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/fec_mxc.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/fsl_mcdmafec.c
+ --------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/fsl_mdio.c
+ ----------------------
+
+ This file contains driver for FSL MDIO interface, which is not part of the
+ networking stack.
+
+ drivers/net/ftgmac100.c
+ -----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ftmac100.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/greth.c
+ -------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/inca-ip_sw.c
+ ------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ks8695eth.c
+ -----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/lan91c96.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/macb.c
+ ------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/mcffec.c
+ --------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/mcfmii.c
+ --------------------
+
+ This file contains MII interface driver for MCF FEC.
+
+ drivers/net/mpc512x_fec.c
+ -------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/mpc5xxx_fec.c
+ -------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/mvgbe.c
+ -------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/natsemi.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/ne2000_base.c
+ -------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process. This driver contains the core
+ implementation of NE2000, which needs a few external functions, implemented by
+ AX88796, NE2000 etc.
+
+ drivers/net/ne2000.c
+ --------------------
+
+ This file implements external functions necessary for native NE2000 compatible
+ networking card to work.
+
+ drivers/net/netconsole.c
+ ------------------------
+
+ This is actually an STDIO driver.
+
+ drivers/net/ns8382x.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/pcnet.c
+ -------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/plb2800_eth.c
+ -------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/rtl8139.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/rtl8169.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/sh_eth.c
+ --------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/smc91111.c
+ ----------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/smc911x.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/tsec.c
+ ------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/tsi108_eth.c
+ ------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/uli526x.c
+ ---------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/vsc7385.c
+ ---------------------
+
+ This is a driver that only uploads firmware to a switch. This is not subject
+ of conversion.
+
+ drivers/net/xilinx_axi_emac.c
+ -----------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
+
+ drivers/net/xilinx_emaclite.c
+ -----------------------------
+
+ This driver uses the standard new networking API, therefore there should be no
+ obstacles throughout the conversion process.
diff --git a/marvell/uboot/doc/driver-model/UDM-pci.txt b/marvell/uboot/doc/driver-model/UDM-pci.txt
new file mode 100644
index 0000000..059a432
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-pci.txt
@@ -0,0 +1,257 @@
+The U-Boot Driver Model Project
+===============================
+PCI subsystem analysis
+======================
+
+Pavel Herrmann <morpheus.ibis@gmail.com>
+2012-03-17
+
+I) Overview
+-----------
+
+ U-Boot already supports multiple PCI busses, stored in a linked-list of
+ pci_controller structures. This structure contains generic driver data, bus
+ interface operations and private data for the driver.
+
+ Bus interface operations for PCI are (names are self-explanatory):
+
+ read_byte()
+ read_word()
+ read_dword()
+ write_byte()
+ write_word()
+ write_dword()
+
+ Each driver has to implement dword operations, and either implement word and
+ byte operations, or use shared $operation_config_$type_via_dword (eg.
+ read_config_byte_via_dword and similar) function. These functions are used
+ for config space I/O (read_config_dword and similar functions of the PCI
+ subsystem), which is used to configure the connected devices for standard MMIO
+ operations. All data transfers by respective device drivers are then done by
+ MMIO
+
+ Each driver also defines a separate init function, which has unique symbol
+ name, and thus more drivers can be compiled in without colliding. This init
+ function is typically called from pci_init_board(), different for each
+ particular board.
+
+ Some boards also define a function called fixup_irq, which gets called after
+ scanning the PCI bus for devices, and should dismiss any interrupts.
+
+ Several drivers are also located in arch/ and should be moved to drivers/pci.
+
+II) Approach
+------------
+
+ The pci_controller structure needs to be broken down to fit the new driver
+ model. Due to a large number of members, this will be done through three
+ distinct accessors, one for memory regions, one for config table and one for
+ everything else. That will make the pci_ops structure look like this:
+
+ struct pci_ops {
+ int (*read_byte)(struct instance *bus, pci_dev_t *dev, int addr,
+ u8 *buf);
+ int (*read_word)(struct instance *bus, pci_dev_t *dev, int addr,
+ u16 *buf);
+ int (*read_dword)(struct instance *bus, pci_dev_t *dev, int addr,
+ u32 *buf);
+ int (*write_byte)(struct instance *bus, pci_dev_t *dev, int addr,
+ u8 val);
+ int (*write_byte)(struct instance *bus, pci_dev_t *dev, int addr,
+ u8 val);
+ int (*write_dword)(struct instance *bus, pci_dev_t *dev, int addr,
+ u32 val);
+ void (*fixup_irq)(struct instance *bus, pci_dev_t *dev);
+ struct pci_region* (*get_region)(struct instance *, uint num);
+ struct pci_config_table* (*get_cfg_table)(struct instance *bus);
+ uint (*get_option)(struct instance * bus, enum pci_option_code op);
+ }
+
+ enum pci_option_code {
+ PCI_OPT_BUS_NUMBER=0,
+ PCI_OPT_REGION_COUNT,
+ PCI_OPT_INDIRECT_TYPE,
+ PCI_OPT_AUTO_MEM,
+ PCI_OPT_AUTO_IO,
+ PCI_OPT_AUTO_PREFETCH,
+ PCI_OPT_AUTO_FB,
+ PCI_OPT_CURRENT_BUS,
+ PCI_OPT_CFG_ADDR,
+ }
+
+ The return value for get_option will be an unsigned integer value for any
+ option code. If the option currently is a pointer to pci_region, it will
+ return an index for get_region function. Special case has to be made for
+ PCI_OPT_CFG_ADDR, which should be interpreted as a pointer, but it is only
+ used for equality in find_hose_by_cfg_addr, and thus can be returned as an
+ uint. Other function using cfg_addr value are read/write functions for
+ specific drivers (especially ops for indirect bridges), and thus have access
+ to private_data of the driver instance.
+
+ The config table accessor will return a pointer to a NULL-terminated array of
+ pci_config_table, which is supplied by the board in platform_data, or NULL if
+ the board didn't specify one. This table is used to override PnP
+ auto-initialization, or to specific initialization functions for non-PNP
+ devices.
+
+ Transparent PCI-PCI bridges will get their own driver, and will forward all
+ operations to operations of their parent bus. This however makes it
+ impossible to use instances to identify devices, as not all devices will be
+ directly visible to the respective bus driver.
+
+ Init functions of controller drivers will be moved to their respective
+ probe() functions, in accordance to the driver model.
+
+ The PCI core will handle all mapping functions currently found in pci.c, as
+ well as proxy functions for read/write operations of the drivers. The PCI
+ core will also handle bus scanning and device configuration.
+
+ The PnP helper functions currently in pci_auto.c will also be a part of PCI
+ core, but they will be exposed only to PCI controller drivers, not to other
+ device drivers.
+
+ The PCI API for device drivers will remain largely unchanged, most drivers
+ will require no changes at all, and all modifications will be limited to
+ changing the pci_controlle into instance*.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ A) drivers in drivers/pci/
+ --------------------------
+
+ pci_indirect.c
+ --------------
+ Shared driver for indirect PCI bridges, several CONFIG macros - will
+ require significant cleanup.
+
+ pci_ixp.c
+ ---------
+ Standard driver, specifies all read/write functions separately.
+
+ pci_sh4.c
+ ---------
+ Shared init function for SH4 drivers, uses dword for read/write ops.
+
+ pci_sh7751.c
+ ------------
+ Standard driver, uses SH4 shared init.
+
+ pci_sh7780.c
+ ------------
+ Standard driver, uses SH4 shared init.
+
+ tsi108_pci.c
+ ------------
+ Standard driver, uses dword for read/write ops.
+
+ fsl_pci_init.c
+ --------------
+ Driver for PCI and PCI-e, uses indirect functions.
+
+ pci_ftpci100.c
+ --------------
+ Standard driver, uses indirect functions, has separate scan/setup
+ functions.
+
+ B) driver in arch/
+ ------------------
+
+ x86/lib/pci_type1.c
+ -------------------
+ Standard driver, specifies all read/write functions separately.
+
+ m68k/cpu/mcf5445x/pci.c
+ -----------------------
+ Standard driver, specifies all read/write functions separately.
+
+ m68k/cpu/mcf547x_8x/pci.c
+ -------------------------
+ Standard driver, specifies all read/write functions separately.
+
+ powerpc/cpu/mpc824x/pci.c
+ -------------------------
+ Standard driver, uses indirect functions, does not setup HW.
+
+ powerpc/cpu/mpc8260/pci.c
+ -------------------------
+ Standard driver, uses indirect functions.
+
+ powerpc/cpu/ppc4xx/4xx_pci.c
+ ----------------------------
+ Standard driver, uses indirect functions.
+
+ powerpc/cpu/ppc4xx/4xx_pcie.c
+ -----------------------------
+ PCI-e driver, specifies all read/write functions separately.
+
+ powerpc/cpu/mpc83xx/pci.c
+ -------------------------
+ Standard driver, uses indirect functions.
+
+ powerpc/cpu/mpc83xx/pcie.c
+ --------------------------
+ PCI-e driver, specifies all read/write functions separately.
+
+ powerpc/cpu/mpc5xxx/pci_mpc5200.c
+ ---------------------------------
+ Standard driver, uses dword for read/write ops.
+
+ powerpc/cpu/mpc512x/pci.c
+ -------------------------
+ Standard driver, uses indirect functions.
+
+ powerpc/cpu/mpc85xx/pci.c
+ -------------------------
+ Standard driver, uses indirect functions, has two busses.
+
+ C) drivers in board/
+ --------------------
+
+ eltec/elppc/pci.c
+ -----------------
+ Standard driver, uses indirect functions.
+
+ amirix/ap1000/pci.c
+ -------------------
+ Standard driver, specifies all read/write functions separately.
+
+ prodrive/p3mx/pci.c
+ -------------------
+ Standard driver, uses dword for read/write ops, has two busses.
+
+ esd/cpci750/pci.c
+ -----------------
+ Standard driver, uses dword for read/write ops, has two busses.
+
+ esd/common/pci.c
+ ----------------
+ Standard driver, uses dword for read/write ops.
+
+ dave/common/pci.c
+ -----------------
+ Standard driver, uses dword for read/write ops.
+
+ ppmc7xx/pci.c
+ -------------
+ Standard driver, uses indirect functions.
+
+ Marvell/db64360/pci.c
+ ---------------------
+ Standard driver, uses dword for read/write ops, has two busses.
+
+ Marvell/db64460/pci.c
+ ---------------------
+ Standard driver, uses dword for read/write ops, has two busses.
+
+ evb64260/pci.c
+ --------------
+ Standard driver, uses dword for read/write ops, has two busses.
+
+ armltd/integrator/pci.c
+ -----------------------
+ Standard driver, specifies all read/write functions separately.
+
+ All drivers will be moved to drivers/pci. Several drivers seem
+ similar/identical, especially those located under board, and may be merged
+ into one.
diff --git a/marvell/uboot/doc/driver-model/UDM-pcmcia.txt b/marvell/uboot/doc/driver-model/UDM-pcmcia.txt
new file mode 100644
index 0000000..d55e89d
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-pcmcia.txt
@@ -0,0 +1,78 @@
+The U-Boot Driver Model Project
+===============================
+PCMCIA analysis
+===============
+Viktor Krivak <viktor.krivak@gmail.com>
+2012-03-17
+
+I) Overview
+-----------
+
+ U-boot implements only 2 methods to interoperate with pcmcia. One to turn
+ device on and other to turn device off. Names of these methods are usually
+ pcmcia_on() and pcmcia_off() without any parameters. Some files in driver
+ directory implements only internal API. These methods aren't used outside
+ driver directory and they are not converted to new driver model.
+
+II) Approach
+-----------
+
+ 1) New API
+ ----------
+
+ Current API is preserved and all internal methods are hiden.
+
+ struct ops {
+ void (*pcmcia_on)(struct instance *i);
+ void (*pcmcia_off)(struct instance *i);
+ }
+
+ 2) Conversion
+ -------------
+
+ In header file pcmcia.h are some other variables which are used for
+ additional configuration. But all have to be moved to platform data or to
+ specific driver implementation.
+
+ 3) Platform data
+ ----------------
+
+ Many boards have custom implementation of internal API. Pointers to these
+ methods are stored in platform_data. But the most implementations for Intel
+ 82365 and compatible PC Card controllers and Yenta-compatible
+ PCI-to-CardBus controllers implement whole API per board. In these cases
+ pcmcia_on() and pcmcia_off() behave only as wrappers and call specific
+ board methods.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ i82365.c
+ --------
+ Driver methods have different name i82365_init() and i82365_exit but
+ all functionality is the same. Board files board/atc/ti113x.c and
+ board/cpc45/pd67290.c use their own implementation of these method.
+ In this case all methods in driver behave only as wrappers.
+
+ marubun_pcmcia.c
+ ----------------
+ Meets standard API behaviour. Simple conversion.
+
+ mpc8xx_pcmcia.c
+ ---------------
+ Meets standard API behaviour. Simple conversion.
+
+ rpx_pcmcia.c
+ ------------
+ Implements only internal API used in other drivers. Non of methods
+ implemented here are used outside driver model.
+
+ ti_pci1410a.c
+ -------------
+ Has different API but methods in this file are never called. Probably
+ dead code.
+
+ tqm8xx_pcmcia.c
+ ---------------
+ Implements only internal API used in other drivers. Non of methods
+ implemented here are used outside driver model.
diff --git a/marvell/uboot/doc/driver-model/UDM-power.txt b/marvell/uboot/doc/driver-model/UDM-power.txt
new file mode 100644
index 0000000..666d553
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-power.txt
@@ -0,0 +1,88 @@
+The U-Boot Driver Model Project
+===============================
+POWER analysis
+==============
+Viktor Krivak <viktor.krivak@gmail.com>
+2012-03-09
+
+I) Overview
+-----------
+
+ 1) Actual state
+ ---------------
+
+ At this moment power doesn't contain API. There are many methods for
+ initialization of some board specific functions but only few does what is
+ expected. Basically only one file contains something meaningful for this
+ driver.
+
+ 2) Current implementation
+ -------------------------
+
+ In file twl6030.c are methods twl6030_stop_usb_charging() and
+ twl6030_start_usb_charging() for start and stop charging from USB. There are
+ also methods to get information about battery state and initialization of
+ battery charging. Only these methods are used in converted API.
+
+
+II) Approach
+------------
+
+ 1) New API
+ ----------
+
+ New API implements only functions specific for managing power. All board
+ specific init methods are moved to other files. Name of methods are
+ self-explanatory.
+
+ struct ops {
+ void (*start_usb_charging)(struct instance *i);
+ void (*stop_usb_charging)(struct instance *i);
+ int (*get_battery_current)(struct instance *i);
+ int (*get_battery_voltage)(struct instance *i);
+ void (*init_battery_charging)(struct instance *i);
+ }
+
+ 2) Conversions of other methods
+ -------------------------------
+
+ Methods that can't be converted to new API are moved to board file or to
+ special file for board hacks.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ ftpmu010.c
+ ----------
+ All methods of this file are moved to another location.
+ void ftpmu010_32768osc_enable(void): Move to boards hacks
+ void ftpmu010_mfpsr_select_dev(unsigned int dev): Move to board file
+ arch/nds32/lib/board.c
+ void ftpmu010_mfpsr_diselect_dev(unsigned int dev): Dead code
+ void ftpmu010_dlldis_disable(void): Dead code
+ void ftpmu010_sdram_clk_disable(unsigned int cr0): Move to board file
+ arch/nds32/lib/board.c
+ void ftpmu010_sdramhtc_set(unsigned int val): Move to board file
+ arch/nds32/lib/board.c
+
+ twl4030.c
+ ---------
+ All methods of this file are moved to another location.
+ void twl4030_power_reset_init(void): Move to board hacks
+ void twl4030_pmrecv_vsel_cfg(u8 vsel_reg, u8 vsel_val, u8 dev_grp,
+ u8 dev_grp_sel): Move to board hacks
+ void twl4030_power_init(void): Move to board hacks
+ void twl4030_power_mmc_init(void): Move to board hacks
+
+ twl6030.c
+ ---------
+ Some methods are converted to new API and rest are moved to another location.
+ void twl6030_stop_usb_charging(void): Convert to new API
+ void twl6030_start_usb_charging(void): Convert to new API
+ int twl6030_get_battery_current(void): Convert to new API
+ int twl6030_get_battery_voltage(void): Convert to new API
+ void twl6030_init_battery_charging(void): Convert to new API
+ void twl6030_power_mmc_init(): Move to board file
+ drivers/mmc/omap_hsmmc.c
+ void twl6030_usb_device_settings(): Move to board file
+ drivers/usb/musb/omap3.c
diff --git a/marvell/uboot/doc/driver-model/UDM-rtc.txt b/marvell/uboot/doc/driver-model/UDM-rtc.txt
new file mode 100644
index 0000000..3640d24
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-rtc.txt
@@ -0,0 +1,253 @@
+=============================
+RTC device subsystem analysis
+=============================
+
+Tomas Hlavacek <tmshlvck@gmail.com>
+2012-03-10
+
+I) Overview
+-----------
+
+U-Boot currently implements one common API for RTC devices. The interface
+is defined in include/rtc.h and comprises of functions and structures:
+
+ struct rtc_time {
+ int tm_sec;
+ int tm_min;
+ int tm_hour;
+ int tm_mday;
+ int tm_mon;
+ int tm_year;
+ int tm_wday;
+ int tm_yday;
+ int tm_isdst;
+ };
+
+ int rtc_get (struct rtc_time *);
+ int rtc_set (struct rtc_time *);
+ void rtc_reset (void);
+
+The functions are implemented by a proper device driver in drivers/rtc
+directory and the driver to be compiled in is selected in a Makefile.
+Drivers are mutually exclusive.
+
+Drivers depends on date code in drivers/rtc/date.c and naturally on board
+specific data.
+
+II) Approach
+------------
+
+ 1) New API
+ ----------
+ In the UDM each rtc driver would register itself by a function
+
+ int rtc_device_register(struct instance *i,
+ struct rtc_device_ops *o);
+
+ The structure being defined as follows:
+
+ struct rtc_device_ops {
+ int (*get_time)(struct instance *i, struct rtc_time *t);
+ int (*set_time)(struct instance *i, struct rtc_time *t);
+ int (*reset)(struct instance *i);
+ };
+
+
+ 2) Conversion thougths
+ ----------------------
+ U-Boot RTC drivers exports the same functions and therefore the conversion
+ of the drivers is straight-forward. There is no initialization needed.
+
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ drivers/rtc/rv3029.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/s3c24x0_rtc.c
+ -------------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/pt7c4338.c
+ ----------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mvrtc.c
+ -------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ftrtc010.c
+ ----------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mpc5xxx.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds164x.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/rs5c372.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/m41t94.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mc13xxx-rtc.c
+ -------------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mcfrtc.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/davinci.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/rx8025.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/bfin_rtc.c
+ ----------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/m41t62.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1306.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mpc8xx.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds3231.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds12887.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1302.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1374.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds174x.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/m41t60.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/m48t35ax.c
+ ----------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/pl031.c
+ -------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/x1205.c
+ -------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/m41t11.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/pcf8563.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mk48t59.c
+ ---------------------
+ Macros needs cleanup. Besides that the driver is standard rtc.
+ Simple conversion is possible.
+
+
+ drivers/rtc/mxsrtc.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1307.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1556.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/rtc4543.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/ds1337.c
+ --------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/isl1208.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/max6900.c
+ ---------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/mc146818.c
+ ----------------------
+ The driver is standard rtc. Simple conversion is possible.
+
+
+ drivers/rtc/at91sam9_rtt.c
+ --------------------------
+ The driver is standard rtc. Simple conversion is possible.
diff --git a/marvell/uboot/doc/driver-model/UDM-serial.txt b/marvell/uboot/doc/driver-model/UDM-serial.txt
new file mode 100644
index 0000000..279e941
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-serial.txt
@@ -0,0 +1,159 @@
+The U-Boot Driver Model Project
+===============================
+Serial I/O analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-20
+
+I) Overview
+-----------
+
+The serial port support currently requires the driver to export the following
+functions:
+
+ serial_putc() ...... Output a character
+ serial_puts() ...... Output string, often done using serial_putc()
+ serial_tstc() ...... Test if incoming character is in a buffer
+ serial_getc() ...... Retrieve incoming character
+ serial_setbrg() .... Configure port options
+ serial_init() ...... Initialize the hardware
+
+The simpliest implementation, supporting only one port, simply defines these six
+functions and calls them. Such calls are scattered all around U-Boot, especiall
+serial_putc(), serial_puts(), serial_tstc() and serial_getc(). The serial_init()
+and serial_setbrg() are often called from platform-dependent places.
+
+It's important to consider current implementation of CONFIG_SERIAL_MULTI though.
+This resides in common/serial.c and behaves as a multiplexer for serial ports.
+This, by calling serial_assign(), allows user to switch I/O from one serial port
+to another. Though the environmental variables "stdin", "stdout", "stderr"
+remain set to "serial".
+
+These variables are managed by the IOMUX. This resides in common/iomux.c and
+manages all console input/output from U-Boot. For serial port, only one IOMUX is
+always registered, called "serial" and the switching of different serial ports
+is done by code in common/serial.c.
+
+On a final note, it's important to mention function default_serial_console(),
+which is platform specific and reports the default serial console for the
+platform, unless proper environment variable overrides this.
+
+II) Approach
+------------
+
+Drivers not using CONFIG_SERIAL_MULTI already will have to be converted to
+similar approach. The probe() function of a driver will call a function
+registering the driver with a STDIO subsystem core, stdio_device_register().
+
+The serial_init() function will now be replaced by probe() function of the
+driver, the rest of the components of the driver will be converted to standard
+STDIO driver calls. See [ UDM-stdio.txt ] for details.
+
+The serial_setbrg() function depends on global data pointer. This is wrong,
+since there is likely to be user willing to configure different baudrate on two
+different serial ports. The function will be replaced with STDIO's "conf()"
+call, with STDIO_CONFIG_SERIAL_BAUDRATE argument.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ altera_jtag_uart.c
+ ------------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ altera_uart.c
+ -------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ arm_dcc.c
+ ---------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible, unless used
+ with CONFIG_ARM_DCC_MULTI. Then it registers another separate IOMUX.
+
+ atmel_usart.c
+ -------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ mcfuart.c
+ ---------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ ns16550.c
+ ---------
+ This driver seems complicated and certain consideration will need to be made
+ during conversion. This driver is implemented in very universal manner,
+ therefore it'll be necessary to properly design it's platform_data.
+
+ opencores_yanu.c
+ ----------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ sandbox.c
+ ---------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial.c
+ --------
+ This is a complementary part of NS16550 UART driver, see above.
+
+ serial_imx.c
+ ------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible. This driver
+ might be removed in favor of serial_mxc.c .
+
+ serial_ixp.c
+ ------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_ks8695.c
+ ---------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_max3100.c
+ ----------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_mxc.c
+ ------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_pl01x.c
+ --------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible, though this
+ driver in fact contains two drivers in total.
+
+ serial_pxa.c
+ ------------
+ This driver is a bit complicated, but due to clean support for
+ CONFIG_SERIAL_MULTI, there are no expected obstructions throughout the
+ conversion process.
+
+ serial_s3c24x0.c
+ ----------------
+ This driver, being quite ad-hoc might need some work to bring back to shape.
+
+ serial_s5p.c
+ ------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_sa1100.c
+ ---------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_sh.c
+ -----------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ serial_xuartlite.c
+ ------------------
+ No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+
+ usbtty.c
+ --------
+ This driver seems very complicated and entangled with USB framework. The
+ conversion might be complicated here.
+
+ arch/powerpc/cpu/mpc512x/serial.c
+ ---------------------------------
+ This driver supports CONFIG_SERIAL_MULTI. This driver will need to be moved to
+ proper place.
diff --git a/marvell/uboot/doc/driver-model/UDM-spi.txt b/marvell/uboot/doc/driver-model/UDM-spi.txt
new file mode 100644
index 0000000..9ba0f84
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-spi.txt
@@ -0,0 +1,200 @@
+The U-Boot Driver Model Project
+===============================
+SPI analysis
+============
+Viktor Krivak <viktor.krivak@gmail.com>
+2012-03-03
+
+I) Overview
+-----------
+
+ 1) The SPI driver
+ -----------------
+
+ At this moment U-Boot provides standard API that consist of 7 functions:
+
+ void spi_init(void);
+ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode);
+ void spi_free_slave(struct spi_slave *slave);
+ int spi_claim_bus(struct spi_slave *slave);
+ void spi_release_bus(struct spi_slave *slave);
+ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags);
+ int spi_cs_is_valid(unsigned int bus, unsigned int cs);
+ void spi_cs_activate(struct spi_slave *slave);
+ void spi_cs_deactivate(struct spi_slave *slave);
+ void spi_set_speed(struct spi_slave *slave, uint hz);
+
+ Method spi_init() is usually empty. All necessary configuration are sets by
+ spi_setup_slave(). But this configuration is usually stored only in memory.
+ No real hardware sets are made. All hardware settings are provided by method
+ spi_claim_bus(). This method claims the bus and it can't be claimed again
+ until it's release. That's mean all calls of method spi_claim_bus() will
+ fail. But lots of cpu implementation don't meet this behaviour.
+ Method spi_release_bus() does exact opposite. It release bus directly by
+ some hardware sets. spi_free_slave() only free memory allocated by
+ spi_setup_slave(). Method spi_xfer() do actually read and write operation
+ throw specified bus and cs. Other methods are self explanatory.
+
+ 2) Current limitations
+ ----------------------
+
+ Theoretically at this moment api allows use more then one bus per device at
+ the time. But in real this can be achieved only when all buses have their
+ own base addresses in memory.
+
+
+II) Approach
+------------
+
+ 1) Claiming bus
+ ---------------
+
+ The current api cannot be used because struct spi_slave have to be in
+ private data. In that case user are prohibited to use different bus on one
+ device at same time. But when base memory address for bus are different.
+ It's possible make more instance of this driver. Otherwise it can't can be
+ done because of hardware limitation.
+
+ 2) API change
+ -------------
+
+ Method spi_init() is moved to probe. Methods spi_setup_slave() and
+ spi_claim_bus() are joined to one method. This method checks if desired bus
+ exists and is available then configure necessary hardware and claims bus.
+ Method spi_release_bus() and spi_free_slave() are also joined to meet this
+ new approach. Other function remain same. Only struct spi_slave was change
+ to instance.
+
+ struct ops {
+ int (*spi_request_bus)(struct instance *i, unsigned int bus,
+ unsigned int cs, unsigned int max_hz,
+ unsigned int mode);
+ void (*spi_release_bus)(struct instance *i);
+ int (*spi_xfer) (struct instance *i, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags);
+ int (*spi_cs_is_valid)(struct instance *i, unsigned int bus,
+ unsigned int cs);
+ void (*spi_cs_activate)(struct instance *i);
+ void (*spi_cs_deactivate)(struct instance *i);
+ void (*spi_set_speed)(struct instance *i, uint hz);
+ }
+
+ 3) Legacy API
+ -------------
+
+ To easy conversion of the whole driver. Original and new api can exist next
+ to each other. New API is designed to be only a wrapper that extracts
+ necessary information from private_data and use old api. When driver can
+ use more than one bus at the time. New API require multiple instance. One
+ for each bus. In this case spi_slave have to be copied in each instance.
+
+ 4) Conversion TIME-LINE
+ -----------------------
+
+ To prevent build corruption api conversion have to be processed in several
+ independent steps. In first step all old API methods are renamed. After that
+ new API and core function are implemented. Next step is conversion of all
+ board init methods to set platform data. After all these steps it is possible
+ to start conversion of all remaining calls. This procedure guarantees that
+ build procedure and binaries are never broken.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ altera_spi.c
+ ------------
+ All methods have designated structure. Simple conversion possible.
+
+ andes_spi.c
+ -----------
+ All methods have designated structure. Simple conversion possible.
+
+ andes_spi.h
+ -----------
+ Support file for andes_spi.c. No conversion is needed.
+
+ armada100_spi.c
+ ---------------
+ All methods have designated structure. Simple conversion possible.
+
+ atmel_dataflash_spi.c
+ ---------------------
+ Wrong placement. Will be moved to another location.
+
+ atmel_spi.c
+ -----------
+ Supports more than one bus. Need some minor change.
+
+ atmel_spi.h
+ -----------
+ Support file for andes_spi.c. No conversion is needed.
+
+ bfin_spi.c
+ ----------
+ Supports more than one bus. Need some minor change.
+
+ cf_spi.c
+ --------
+ Cooperate with some cpu specific methods from other files. Hard conversion.
+
+ davinci_spi.c
+ -------------
+ All methods have designated structure. Simple conversion possible.
+
+ davinci_spi.h
+ -------------
+ Support file for davinci_spi.h. No conversion is needed.
+
+ fsl_espi.c
+ ----------
+ All methods have designated structure. Simple conversion possible.
+
+ kirkwood_spi.c
+ --------------
+ All methods have designated structure. Simple conversion possible.
+
+ mpc8xxx_spi.c
+ -------------
+ All methods have designated structure. Simple conversion possible.
+
+ mpc52xx_spi.c
+ -------------
+ All methods have designated structure. Simple conversion possible.
+
+ mxc_spi.c
+ ---------
+ All methods have designated structure. Simple conversion possible.
+
+ mxs_spi.c
+ ---------
+ All methods have designated structure. Simple conversion possible.
+
+ oc_tiny_spi.c
+ -------------
+ Supports more than one bus. Need some minor change.
+
+ omap3_spi.c
+ -----------
+ Supports more than one bus. Need some minor change.
+
+ omap3_spi.h
+ -----------
+ Support file for omap3_spi.c. No conversion is needed.
+
+ sh_spi.c
+ --------
+ All methods have designated structure. Simple conversion possible.
+
+ sh_spi.h
+ --------
+ Support file for sh_spi.h. No conversion is needed.
+
+ soft_spi.c
+ ----------
+ Use many board specific method linked from other files. Need careful debugging.
+
+ tegra2_spi.c
+ ------------
+ Some hardware specific problem when releasing bus.
diff --git a/marvell/uboot/doc/driver-model/UDM-stdio.txt b/marvell/uboot/doc/driver-model/UDM-stdio.txt
new file mode 100644
index 0000000..156627b
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-stdio.txt
@@ -0,0 +1,191 @@
+The U-Boot Driver Model Project
+===============================
+I/O system analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-20
+
+I) Overview
+-----------
+
+The console input and output is currently done using the STDIO subsystem in
+U-Boot. The design of this subsystem is already flexible enough to be easily
+converted to new driver model approach. Minor changes will need to be done
+though.
+
+Each device that wants to register with STDIO subsystem has to define struct
+stdio_dev, defined in include/stdio_dev.h and containing the following fields:
+
+struct stdio_dev {
+ int flags; /* Device flags: input/output/system */
+ int ext; /* Supported extensions */
+ char name[16]; /* Device name */
+
+/* GENERAL functions */
+
+ int (*start) (void); /* To start the device */
+ int (*stop) (void); /* To stop the device */
+
+/* OUTPUT functions */
+
+ void (*putc) (const char c); /* To put a char */
+ void (*puts) (const char *s); /* To put a string (accelerator) */
+
+/* INPUT functions */
+
+ int (*tstc) (void); /* To test if a char is ready... */
+ int (*getc) (void); /* To get that char */
+
+/* Other functions */
+
+ void *priv; /* Private extensions */
+ struct list_head list;
+};
+
+Currently used flags are DEV_FLAGS_INPUT, DEV_FLAGS_OUTPUT and DEV_FLAGS_SYSTEM,
+extensions being only one, the DEV_EXT_VIDEO.
+
+The private extensions are now used as a per-device carrier of private data and
+finally list allows this structure to be a member of linked list of STDIO
+devices.
+
+The STDIN, STDOUT and STDERR routing is handled by environment variables
+"stdin", "stdout" and "stderr". By configuring the variable to the name of a
+driver, functions of such driver are called to execute that particular
+operation.
+
+II) Approach
+------------
+
+ 1) Similarity of serial, video and keyboard drivers
+ ---------------------------------------------------
+
+ All of these drivers can be unified under the STDIO subsystem if modified
+ slightly. The serial drivers basically define both input and output functions
+ and need function to configure baudrate. The keyboard drivers provide only
+ input. On the other hand, video drivers provide output, but need to be
+ configured in certain way. This configuration might be dynamic, therefore the
+ STDIO has to be modified to provide such flexibility.
+
+ 2) Unification of serial, video and keyboard drivers
+ ----------------------------------------------------
+
+ Every STDIO device would register a structure containing operation it supports
+ with the STDIO core by calling:
+
+ int stdio_device_register(struct instance *i, struct stdio_device_ops *o);
+
+ The structure being defined as follows:
+
+ struct stdio_device_ops {
+ void (*putc)(struct instance *i, const char c);
+ void (*puts)(struct instance *i, const char *s); /* OPTIONAL */
+
+ int (*tstc)(struct instance *i);
+ int (*getc)(struct instance *i);
+
+ int (*init)(struct instance *i);
+ int (*exit)(struct instance *i);
+ int (*conf)(struct instance *i, enum stdio_config c, const void *data);
+ };
+
+ The "putc()" function will emit a character, the "puts()" function will emit a
+ string. If both of these are set to NULL, the device is considered STDIN only,
+ aka input only device.
+
+ The "getc()" retrieves a character from a STDIN device, while "tstc()" tests
+ if there is a character in the buffer of STDIN device. In case these two are
+ set to NULL, this device is STDOUT / STDERR device.
+
+ Setting all "putc()", "puts()", "getc()" and "tstc()" calls to NULL isn't an
+ error condition, though such device does nothing. By instroducing tests for
+ these functions being NULL, the "flags" and "ext" fields from original struct
+ stdio_dev can be eliminated.
+
+ The "init()" and "exit()" calls are replacement for "start()" and "exit()"
+ calls in the old approach. The "priv" part of the old struct stdio_dev will be
+ replaced by common private data in the driver model and the struct list_head
+ list will be eliminated by introducing common STDIO core, that tracks all the
+ STDIO devices.
+
+ Lastly, the "conf()" call will allow the user to configure various options of
+ the driver. The enum stdio_config contains all possible configuration options
+ available to the STDIO devices, const void *data being the argument to be
+ configured. Currently, the enum stdio_config will contain at least the
+ following options:
+
+ enum stdio_config {
+ STDIO_CONFIG_SERIAL_BAUDRATE,
+ };
+
+ 3) Transformation of stdio routing
+ ----------------------------------
+
+ By allowing multiple instances of drivers, the environment variables "stdin",
+ "stdout" and "stderr" can no longer be set to the name of the driver.
+ Therefore the STDIO core, tracking all of the STDIO devices in the system will
+ need to have a small amount of internal data for each device:
+
+ struct stdio_device_node {
+ struct instance *i;
+ struct stdio_device_ops *ops;
+ uint8_t id;
+ uint8_t flags;
+ struct list_head list;
+ }
+
+ The "id" is the order of the instance of the same driver. The "flags" variable
+ allows multiple drivers to be used at the same time and even for different
+ purpose. The following flags will be defined:
+
+ STDIO_FLG_STDIN ..... This device will be used as an input device. All input
+ from all devices with this flag set will be received
+ and passed to the upper layers.
+ STDIO_FLG_STDOUT .... This device will be used as an output device. All
+ output sent to stdout will be routed to all devices
+ with this flag set.
+ STDIO_FLG_STDERR .... This device will be used as an standard error output
+ device. All output sent to stderr will be routed to
+ all devices with this flag set.
+
+ The "list" member of this structure allows to have a linked list of all
+ registered STDIO devices.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+For in-depth analysis of serial port drivers, refer to [ UDM-serial.txt ].
+For in-depth analysis of keyboard drivers, refer to [ UDM-keyboard.txt ].
+For in-depth analysis of video drivers, refer to [ UDM-video.txt ].
+
+ arch/blackfin/cpu/jtag-console.c
+ --------------------------------
+ This driver is a classic STDIO driver, no problem with conversion is expected.
+
+ board/mpl/pati/pati.c
+ ---------------------
+ This driver registers with the STDIO framework, though it uses a lot of ad-hoc
+ stuff which will need to be sorted out.
+
+ board/netphone/phone_console.c
+ ------------------------------
+ This driver is a classic STDIO driver, no problem with conversion is expected.
+
+ drivers/net/netconsole.c
+ ------------------------
+ This driver is a classic STDIO driver, no problem with conversion is expected.
+
+IV) Other involved files (To be removed)
+----------------------------------------
+
+common/cmd_console.c
+common/cmd_log.c
+common/cmd_terminal.c
+common/console.c
+common/fdt_support.c
+common/iomux.c
+common/lcd.c
+common/serial.c
+common/stdio.c
+common/usb_kbd.c
+doc/README.iomux
diff --git a/marvell/uboot/doc/driver-model/UDM-tpm.txt b/marvell/uboot/doc/driver-model/UDM-tpm.txt
new file mode 100644
index 0000000..0beff4a
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-tpm.txt
@@ -0,0 +1,48 @@
+The U-Boot Driver Model Project
+===============================
+TPM system analysis
+===================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-23
+
+I) Overview
+-----------
+
+There is currently only one TPM chip driver available and therefore the API
+controlling it is very much based on this. The API is very simple:
+
+ int tis_open(void);
+ int tis_close(void);
+ int tis_sendrecv(const u8 *sendbuf, size_t send_size,
+ u8 *recvbuf, size_t *recv_len);
+
+The command operating the TPM chip only provides operations to send and receive
+bytes from the chip.
+
+II) Approach
+------------
+
+The API can't be generalised too much considering there's only one TPM chip
+supported. But it's a good idea to split the tis_sendrecv() function in two
+functions. Therefore the new API will use register the TPM chip by calling:
+
+ tpm_device_register(struct instance *i, const struct tpm_ops *ops);
+
+And the struct tpm_ops will contain the following members:
+
+ struct tpm_ops {
+ int (*tpm_open)(struct instance *i);
+ int (*tpm_close)(struct instance *i);
+ int (*tpm_send)(const uint8_t *buf, const size_t size);
+ int (*tpm_recv)(uint8_t *buf, size_t *size);
+ };
+
+The behaviour of "tpm_open()" and "tpm_close()" will basically copy the
+behaviour of "tis_open()" and "tis_close()". The "tpm_send()" will be based on
+the "tis_senddata()" and "tis_recv()" will be based on "tis_readresponse()".
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+There is only one in-tree driver present, the "drivers/tpm/generic_lpc_tpm.c",
+which will be simply converted as outlined in previous chapter.
diff --git a/marvell/uboot/doc/driver-model/UDM-twserial.txt b/marvell/uboot/doc/driver-model/UDM-twserial.txt
new file mode 100644
index 0000000..5f2c5a3
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-twserial.txt
@@ -0,0 +1,47 @@
+==================================
+TWserial device subsystem analysis
+==================================
+
+Tomas Hlavacek<tmshlvck@gmail.com>
+2012-03-21
+
+I) Overview
+-----------
+
+U-Boot currently implements one common API for TWSerial devices. The interface
+is defined in include/tws.h and comprises of functions:
+
+ int tws_read(uchar *buffer, int len);
+ int tws_write(uchar *buffer, int len);
+
+The functions are implemented by a proper device driver in drivers/twserial
+directory and the driver to be compiled in is selected in a Makefile. There is
+only one driver present now.
+
+The driver depends on ad-hoc code in board specific data, namely functions:
+
+ void tws_ce(unsigned bit);
+ void tws_wr(unsigned bit);
+ void tws_clk(unsigned bit);
+ void tws_data(unsigned bit);
+ unsigned tws_data_read(void);
+ void tws_data_config_output(unsigned output);
+
+implemented in include/configs/inka4x0.h .
+
+II) Approach
+------------
+
+ U-Boot TWserial drivers exports two simple functions and therefore the conversion
+ of the driver and creating a core for it is not needed. It should be consolidated
+ with include/configs/inka4x0.h and taken to the misc/ dir.
+
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ drivers/twserial/soft_tws.c
+ ---------------------------
+ The driver is the only TWserial driver. The ad-hoc part in
+ include/configs/inka4x0.h and the core soft_tws driver should be consolidated
+ to one compact driver and moved to misc/ .
diff --git a/marvell/uboot/doc/driver-model/UDM-usb.txt b/marvell/uboot/doc/driver-model/UDM-usb.txt
new file mode 100644
index 0000000..5ce85b5
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-usb.txt
@@ -0,0 +1,94 @@
+The U-Boot Driver Model Project
+===============================
+USB analysis
+============
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-16
+
+I) Overview
+-----------
+
+ 1) The USB Host driver
+ ----------------------
+ There are basically four or five USB host drivers. All such drivers currently
+ provide at least the following fuctions:
+
+ usb_lowlevel_init() ... Do the initialization of the USB controller hardware
+ usb_lowlevel_stop() ... Do the shutdown of the USB controller hardware
+
+ usb_event_poll() ...... Poll interrupt from USB device, often used by KBD
+
+ submit_control_msg() .. Submit message via Control endpoint
+ submit_int_msg() ...... Submit message via Interrupt endpoint
+ submit_bulk_msg() ..... Submit message via Bulk endpoint
+
+
+ This allows for the host driver to be easily abstracted.
+
+ 2) The USB hierarchy
+ --------------------
+
+ In the current implementation, the USB Host driver provides operations to
+ communicate via the USB bus. This is realised by providing access to a USB
+ root port to which an USB root hub is attached. The USB bus is scanned and for
+ each newly found device, a struct usb_device is allocated. See common/usb.c
+ and include/usb.h for details.
+
+II) Approach
+------------
+
+ 1) The USB Host driver
+ ----------------------
+
+ Converting the host driver will follow the classic driver model consideration.
+ Though, the host driver will have to call a function that registers a root
+ port with the USB core in it's probe() function, let's call this function
+
+ usb_register_root_port(&ops);
+
+ This will allow the USB core to track all available root ports. The ops
+ parameter will contain structure describing operations supported by the root
+ port:
+
+ struct usb_port_ops {
+ void (*usb_event_poll)();
+ int (*submit_control_msg)();
+ int (*submit_int_msg)();
+ int (*submit_bulk_msg)();
+ }
+
+ 2) The USB hierarchy and hub drivers
+ ------------------------------------
+
+ Converting the USB heirarchy should be fairy simple, considering the already
+ dynamic nature of the implementation. The current usb_hub_device structure
+ will have to be converted to a struct instance. Every such instance will
+ contain components of struct usb_device and struct usb_hub_device in it's
+ private data, providing only accessors in order to properly encapsulate the
+ driver.
+
+ By registering the root port, the USB framework will instantiate a USB hub
+ driver, which is always present, the root hub. The root hub and any subsequent
+ hub instance is represented by struct instance and it's private data contain
+ amongst others common bits from struct usb_device.
+
+ Note the USB hub driver is partly defying the usual method of registering a
+ set of callbacks to a particular core driver. Instead, a static set of
+ functions is defined and the USB hub instance is passed to those. This creates
+ certain restrictions as of how the USB hub driver looks, but considering the
+ specification for USB hub is given and a different type of USB hub won't ever
+ exist, this approach is ok:
+
+ - Report how many ports does this hub have:
+ uint get_nr_ports(struct instance *hub);
+ - Get pointer to device connected to a port:
+ struct instance *(*get_child)(struct instance *hub, int port);
+ - Instantiate and configure device on port:
+ struct instance *(*enum_dev_on_port)(struct instance *hub, int port);
+
+ 3) USB device drivers
+ ---------------------
+
+ The USB device driver, in turn, will have to register various ops structures
+ with certain cores. For example, USB disc driver will have to register it's
+ ops with core handling USB discs etc.
diff --git a/marvell/uboot/doc/driver-model/UDM-video.txt b/marvell/uboot/doc/driver-model/UDM-video.txt
new file mode 100644
index 0000000..e67e9e4
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-video.txt
@@ -0,0 +1,74 @@
+The U-Boot Driver Model Project
+===============================
+Video output analysis
+=====================
+Marek Vasut <marek.vasut@gmail.com>
+2012-02-20
+
+I) Overview
+-----------
+
+The video drivers are most often registered with video subsystem. This subsystem
+often expects to be allowed access to framebuffer of certain parameters. This
+subsystem also provides calls for STDIO subsystem to allow it to output
+characters on the screen. For this part, see [ UDM-stdio.txt ].
+
+Therefore the API has two parts, the video driver part and the part where the
+video driver core registers with STDIO API.
+
+The video driver part will follow the current cfb_console approach, though
+allowing it to be more dynamic.
+
+II) Approach
+------------
+
+Registering the video driver into the video driver core is done by calling the
+following function from the driver probe() function:
+
+ video_device_register(struct instance *i, GraphicDevice *gd);
+
+Because the video driver core is in charge or rendering characters as well as
+bitmaps on the screen, it will in turn call stdio_device_register(i, so), where
+"i" is the same instance as the video driver's one. But "so" will be special
+static struct stdio_device_ops handling the character output.
+
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ arch/powerpc/cpu/mpc8xx/video.c
+ -------------------------------
+ This driver copies the cfb_console [ see drivers/video/cfb_console.c ]
+ approach and acts only as a STDIO device. Therefore there are currently two
+ possible approaches, first being the conversion of this driver to usual STDIO
+ device and second, long-term one, being conversion of this driver to video
+ driver that provides console.
+
+ arch/x86/lib/video.c
+ --------------------
+ This driver registers two separate STDIO devices and should be therefore
+ converted as such.
+
+ board/bf527-ezkit/video.c
+ -------------------------
+ This driver seems bogus as it behaves as STDIO device, but provides no input
+ or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
+ or present otherwise than as a dead code/define.
+
+ board/bf533-stamp/video.c
+ -------------------------
+ This driver seems bogus as it behaves as STDIO device, but provides no input
+ or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
+ or present otherwise than as a dead code/define.
+
+ board/bf548-ezkit/video.c
+ -------------------------
+ This driver seems bogus as it behaves as STDIO device, but provides no input
+ or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
+ or present otherwise than as a dead code/define.
+
+ board/cm-bf548/video.c
+ ----------------------
+ This driver seems bogus as it behaves as STDIO device, but provides no input
+ or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
+ or present otherwise than as a dead code/define.
diff --git a/marvell/uboot/doc/driver-model/UDM-watchdog.txt b/marvell/uboot/doc/driver-model/UDM-watchdog.txt
new file mode 100644
index 0000000..3f13063
--- /dev/null
+++ b/marvell/uboot/doc/driver-model/UDM-watchdog.txt
@@ -0,0 +1,329 @@
+The U-Boot Driver Model Project
+===============================
+Watchdog device subsystem analysis
+==================================
+
+Tomas Hlavacek <tmshlvck@gmail.com>
+2012-03-09
+
+I) Overview
+-----------
+
+U-Boot currently implements an API for HW watchdog devices as explicit drivers
+in drivers/watchdog directory. There are also drivers for both hardware and
+software watchdog on particular CPUs implemented in arch/*/cpu/*/cpu.c. There
+are macros in include/watchdog.h that selects between SW and HW watchdog and
+assembly SW implementation.
+
+The current common interface comprises of one set out of these two possible
+variants:
+
+ 1)
+ void watchdog_reset(void);
+ int watchdog_disable(void);
+ int watchdog_init(void);
+
+ 2)
+ void hw_watchdog_reset(void);
+ void hw_watchdog_init(void);
+
+The watchdog implementations are also spread through board/*/*.c that in
+some cases. The API and semantics is in most cases same as the above
+mentioned common functions.
+
+
+II) Approach
+------------
+
+ 1) New API
+ ----------
+
+ In the UDM each watchdog driver would register itself by a function
+
+ int watchdog_device_register(struct instance *i,
+ const struct watchdog_device_ops *o);
+
+ The structure being defined as follows:
+
+ struct watchdog_device_ops {
+ int (*disable)(struct instance *i);
+ void (*reset)(struct instance *i);
+ };
+
+ The watchdog_init() function will be dissolved into probe() function.
+
+ 2) Conversion thougths
+ ----------------------
+
+ Conversion of watchdog implementations to a new API could be divided
+ to three subsections: a) HW implementations, which are mostly compliant
+ to the above mentioned API; b) SW implementations, which are compliant
+ to the above mentioned API and c) SW implementations that are not compliant
+ to the API and has to be rectified or partially rewritten.
+
+III) Analysis of in-tree drivers
+--------------------------------
+
+ drivers/watchdog/at91sam9_wdt.c
+ -------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ drivers/watchdog/ftwdt010_wdt.c
+ -------------------------------
+ The driver is ad-hoc HW watchdog. Conversion has to take into account
+ driver parts spread in include/faraday/*. Restructuring the driver and
+ code cleanup has to be considered.
+
+
+ arch/arm/cpu/arm1136/mx31/timer.c
+ ---------------------------------
+ The driver is semi-standard ad-hoc HW watchdog. Conversion has to take
+ into account driver parts spread in the timer.c file.
+
+
+ arch/arm/cpu/arm926ejs/davinci/timer.c
+ --------------------------------------
+ The driver is ad-hoc semi-standard HW watchdog. Conversion has to take
+ into account driver parts spread in the timer.c file.
+
+
+ arch/arm/cpu/armv7/omap-common/hwinit-common.c
+ ----------------------------------------------
+ The driver is non-standard ad-hoc HW watchdog. Conversion is possible
+ but functions has to be renamed and constants moved to another places.
+
+
+ arch/arm/cpu/armv7/omap3/board.c
+ --------------------------------
+ The driver is non-standard ad-hoc HW watchdog. Conversion is possible
+ but functions has to be renamed and constants moved to another places.
+
+
+ arch/blackfin/cpu/watchdog.c
+ ----------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/m68k/cpu/mcf523x/cpu.c
+ ---------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/m68k/cpu/mcf52x2/cpu.c
+ ---------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/m68k/cpu/mcf532x/cpu.c
+ ---------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/m68k/cpu/mcf547x_8x/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog (there is slight naming convention
+ violation that has to be rectified). Simple conversion is possible.
+
+
+ arch/powerpc/cpu/74xx_7xx/cpu.c
+ -------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc512x/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc5xx/cpu.c
+ -----------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc5xxx/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc8260/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc83xx/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc85xx/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc86xx/cpu.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/mpc8xx/cpu.c
+ -----------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/powerpc/cpu/ppc4xx/cpu.c
+ -----------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/sh/cpu/sh2/watchdog.c
+ --------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/sh/cpu/sh3/watchdog.c
+ --------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ arch/sh/cpu/sh4/watchdog.c
+ --------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/amcc/luan/luan.c
+ ----------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/amcc/yosemite/yosemite.c
+ ------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/apollon/apollon.c
+ -----------------------
+ The driver is standard HW watchdog however the watchdog_init()
+ function is called in early initialization. Simple conversion is possible.
+
+
+ board/bmw/m48t59y.c
+ -------------------
+ Special watchdog driver. Dead code. To be removed.
+
+
+ board/davedenx/qong/qong.c
+ --------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/dvlhost/watchdog.c
+ ------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/eNET/eNET.c
+ -----------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/eltec/elppc/elppc.c
+ -------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/enbw/enbw_cmc/enbw_cmc.c
+ ------------------------------
+ Only function proxy call. Code cleanup needed.
+
+
+ board/freescale/mx31pdk/mx31pdk.c
+ ---------------------------------
+ Only function proxy call. Code cleanup needed.
+
+
+ board/gth2/gth2.c
+ -----------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/lwmon5/lwmon5.c
+ ---------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/manroland/mucmc52/mucmc52.c
+ ---------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/manroland/uc101/uc101.c
+ -----------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/mousse/m48t59y.c
+ ----------------------
+ Special watchdog driver. Dead code. To be removed.
+
+
+ board/mvblue/mvblue.c
+ ---------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/netphone/netphone.c
+ -------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/netta/netta.c
+ -------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/netta2/netta2.c
+ ---------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/omicron/calimain/calimain.c
+ ---------------------------------
+ Only function proxy call. Code cleanup needed.
+
+
+ board/pcs440ep/pcs440ep.c
+ -------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/stx/stxxtc/stxxtc.c
+ -------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/ti/omap2420h4/omap2420h4.c
+ --------------------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/ttcontrol/vision2/vision2.c
+ ---------------------------------
+ The driver is standard HW watchdog but namespace is polluted by
+ non-standard macros. Simple conversion is possible, code cleanup
+ needed.
+
+
+ board/v38b/v38b.c
+ -----------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/ve8313/ve8313.c
+ ---------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
+
+
+ board/w7o/watchdog.c
+ --------------------
+ The driver is standard HW watchdog. Simple conversion is possible.
diff --git a/marvell/uboot/doc/feature-removal-schedule.txt b/marvell/uboot/doc/feature-removal-schedule.txt
new file mode 100644
index 0000000..1c79c14
--- /dev/null
+++ b/marvell/uboot/doc/feature-removal-schedule.txt
@@ -0,0 +1,59 @@
+The following is a list of files and features that are going to be
+removed from the U-Boot source tree. Every entry should contain what
+exactly is going away, when it will be gone, why it is being removed,
+and who is going to be doing the work. When the feature is removed
+from U-Boot, its corresponding entry should also be removed from this
+file.
+
+---------------------------
+
+What: Remove unused CONFIG_SYS_MEMTEST_START/END
+When: Release v2013.10
+
+Why: As the 'mtest' command is no longer default, a number of platforms
+ have not opted to turn the command back on and thus provide unused
+ defines (which are likely to be propogated to new platforms from
+ copy/paste). Remove these defines when unused.
+
+Who: Tom Rini <trini@ti.com>
+
+---------------------------
+
+What: Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL
+When: Release v2013.07
+
+Why: When set these options enable "all" of the pads and clocks found
+ on OMAP4/5 platforms, so that the Linux Kernel does not have to.
+ It has been agreed that this goes against the U-Boot design
+ philosophy and since f3f98bb0 we have not enabled more than is
+ used in U-Boot. The kernel has been updating drivers to enable
+ rather than assume pads/clocks have been enabled already. Our
+ expectation is that by v2013.07 a suitable kernel shall exist that
+ does not need these options set for a reasonable I/O set to function.
+
+Who: Tom Rini <trini@ti.com> and Sricharan R <r.sricharan@ti.com>
+
+---------------------------
+
+What: Users of the legacy miiphy_* code
+When: undetermined
+
+Why: We now have a PHY library, which allows everyone to share PHY
+ drivers. All new drivers should use this infrastructure, and
+ all old drivers should get converted to use it.
+
+Who: Andy Fleming <afleming@freescale.com> and driver maintainers
+
+---------------------------
+
+What: GPL cleanup
+When: August 2009
+Why: Over time, a couple of files have sneaked in into the U-Boot
+ source code that are either missing a valid GPL license
+ header or that carry a license that is incompatible with the
+ GPL.
+ Such files shall be removed from the U-Boot source tree.
+ See http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files
+ for an old and probably incomplete list of such files.
+
+Who: Wolfgang Denk <wd@denx.de> and board maintainers
diff --git a/marvell/uboot/doc/git-mailrc b/marvell/uboot/doc/git-mailrc
new file mode 100644
index 0000000..251586e
--- /dev/null
+++ b/marvell/uboot/doc/git-mailrc
@@ -0,0 +1,112 @@
+# To use this file, run in your u-boot tree:
+# git config sendemail.aliasesfile doc/git-mailrc
+# git config sendemail.aliasfiletype mutt
+#
+# Then when sending patches, you can use:
+# git send-email --to u-boot --cc i2c ...
+
+alias uboot u-boot@lists.denx.de
+alias u-boot uboot
+
+# Maintainer aliases. Use the same alias here as patchwork to keep
+# things simple and easy to look up/coordinate.
+alias aaribaud Albert Aribaud <albert.u.boot@aribaud.net>
+alias abiessmann Andreas Bießmann <andreas.devel@googlemail.com>
+alias afleming Andy Fleming <afleming@freescale.com>
+alias ag Anatolij Gustschin <agust@denx.de>
+alias galak Kumar Gala <galak@kernel.crashing.org>
+alias gruss Graeme Russ <graeme.russ@gmail.com>
+alias hs Heiko Schocher <hs@denx.de>
+alias iwamatsu Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+alias jagan Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+alias jasonjin Jason Jin <jason.jin@freescale.com>
+alias jhersh Joe Hershberger <joe.hershberger@gmail.com>
+alias kimphill Kim Phillips <kim.phillips@freescale.com>
+alias macpaul Macpaul Lin <macpaul@andestech.com>
+alias marex Marek Vasut <marex@denx.de>
+alias monstr Michal Simek <monstr@monstr.eu>
+alias panto Pantelis Antoniou <panto@antoniou-consulting.com>
+alias prafulla Prafulla Wadaskar <prafulla@marvell.com>
+alias prom Minkyu Kang <mk7.kang@samsung.com>
+alias rbohmer Remy Bohmer <linux@bohmer.net>
+alias reinhardm Reinhard Meyer <u-boot@emk-elektronik.de>
+alias sbabic Stefano Babic <sbabic@denx.de>
+alias scottwood Scott Wood <scottwood@freescale.com>
+alias sjg Simon Glass <sjg@chromium.org>
+alias smcnutt Scott McNutt <smcnutt@psyent.com>
+alias sonic Sonic Zhang <sonic.adi@gmail.com>
+alias stroese Stefan Roese <sr@denx.de>
+alias trini Tom Rini <trini@ti.com>
+alias vapier Mike Frysinger <vapier@gentoo.org>
+alias wd Wolfgang Denk <wd@denx.de>
+
+# Architecture aliases
+alias arch arm, avr32, bfin, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, sparc, x86
+alias arches arch
+
+alias arm uboot, aaribaud
+alias at91 uboot, abiessmann
+alias davinci ti
+alias imx uboot, sbabic
+alias kirkwood uboot, prafulla
+alias omap ti
+alias pxa uboot, marex
+alias rmobile uboot, iwamatsu
+alias s3c samsung
+alias s5pc samsung
+alias samsung uboot, prom
+alias tegra uboot, sjg, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com>
+alias tegra2 tegra
+alias ti uboot, trini
+
+alias avr32 uboot, abiessmann
+
+alias bfin uboot, vapier, sonic
+alias blackfin bfin
+
+alias m68k uboot, jasonjin
+alias coldfire m68k
+
+alias microblaze uboot, monstr
+alias mb microblaze
+
+alias mips uboot, Shinya Kuribayashi <skuribay@pobox.com>
+
+alias nds32 uboot, macpaul
+
+alias nios uboot, Thomas Chou <thomas@wytron.com.tw>, smcnutt
+alias nios2 nios
+
+alias powerpc uboot, afleming, kimphill, galak, stroese, wd
+alias ppc powerpc
+alias mpc5xxx uboot, wd
+alias mpc8xx uboot, wd
+alias mpc82xx uboot, wd
+alias mpc83xx uboot, kimphill
+alias mpc85xx uboot, afleming, galak
+alias mpc86xx uboot, afleming, galak
+alias ppc4xx uboot, stroese
+alias ppc7xx uboot, wd
+alias ppc74xx uboot, wd
+
+alias sandbox sjg
+alias sb sandbox
+
+alias sparc uboot, Daniel Hellstrom <daniel@gaisler.com>
+
+alias superh uboot, iwamatsu
+alias sh superh
+
+alias x86 uboot, sjg, gruss
+
+# Subsystem aliases
+alias cfi uboot, stroese
+alias kerneldoc uboot, marex
+alias fdt uboot, Jerry Van Baren <vanbaren@cideas.com>
+alias i2c uboot, hs
+alias mmc uboot, panto
+alias nand uboot, scottwood
+alias net uboot, jhersh
+alias spi uboot, jagan
+alias usb uboot, marex
+alias video uboot, ag
diff --git a/marvell/uboot/doc/kwboot.1 b/marvell/uboot/doc/kwboot.1
new file mode 100644
index 0000000..25fe69a
--- /dev/null
+++ b/marvell/uboot/doc/kwboot.1
@@ -0,0 +1,84 @@
+.TH KWBOOT 1 "2012-05-19"
+
+.SH NAME
+kwboot \- Boot Marvell Kirkwood SoCs over a serial link.
+.SH SYNOPSIS
+.B kwboot
+.RB [ "-b \fIimage\fP" ]
+.RB [ "-p" ]
+.RB [ "-t" ]
+.RB [ "-B \fIbaudrate\fP" ]
+.RB \fITTY\fP
+.SH "DESCRIPTION"
+
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+platform over their integrated UART. Boot image files will typically
+contain a second stage boot loader, such as U-Boot. The image file
+must conform to Marvell's BootROM firmware image format
+(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
+
+Following power-up or a system reset, system BootROM code polls the
+UART for a brief period of time, sensing a handshake message which
+initiates an image upload. This program sends this boot message until
+it receives a positive acknowledgement. The image is transfered using
+Xmodem.
+
+Additionally, this program implements a minimal terminal mode, which
+can be used either standalone, or entered immediately following boot
+image transfer completion. This is often useful to catch early boot
+messages, or to manually interrupt a default boot procedure performed
+by the second-stage loader.
+
+.SH "OPTIONS"
+
+.TP
+.BI "\-b \fIimage\fP"
+Handshake; then upload file \fIimage\fP over \fITTY\fP.
+
+Note that for the encapsulated boot code to be executed, \fIimage\fP
+must be of type "UART boot" (0x69). Boot images of different types,
+such as backup images of vendor firmware downloaded from flash memory
+(type 0x8B), will not work (or not as expected). See \fB-p\fP for a
+workaround.
+
+This mode writes handshake status and upload progress indication to
+stdout.
+
+.TP
+.BI "\-p"
+In combination with \fB-b\fP, patches the header in \fIimage\fP prior
+to upload, to "UART boot" type.
+
+This option attempts on-the-fly conversion of some none-UART image
+types, such as images which were originally formatted to be stored in
+flash memory.
+
+Conversion is performed in memory. The contents of \fIimage\fP will
+not be altered.
+
+.TP
+.BI "\-t"
+Run a terminal program, connecting standard input and output to
+.RB \fITTY\fP.
+
+If used in combination with \fB-b\fP, terminal mode is entered
+immediately following a successful image upload.
+
+If standard I/O streams connect to a console, this mode will terminate
+after receiving 'ctrl-\\' followed by 'c' from console input.
+
+.TP
+.BI "\-B \fIbaudrate\fP"
+Adjust the baud rate on \fITTY\fP. Default rate is 115200.
+
+.SH "SEE ALSO"
+.PP
+\fBmkimage\fP(1)
+
+.SH "AUTHORS"
+
+Daniel Stodden <daniel.stodden@gmail.com>
+.br
+Luka Perkov <luka@openwrt.org>
+.br
+David Purdy <david.c.purdy@gmail.com>
diff --git a/marvell/uboot/doc/mkimage.1 b/marvell/uboot/doc/mkimage.1
new file mode 100644
index 0000000..14374da
--- /dev/null
+++ b/marvell/uboot/doc/mkimage.1
@@ -0,0 +1,185 @@
+.TH MKIMAGE 1 "2010-05-16"
+
+.SH NAME
+mkimage \- Generate image for U-Boot
+.SH SYNOPSIS
+.B mkimage
+.RB "\-l [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " \-f [" "image tree source file" "]" " [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " \-F [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " (legacy mode)"
+
+.SH "DESCRIPTION"
+The
+.B mkimage
+command is used to create images for use with the U-Boot boot loader.
+These images can contain the linux kernel, device tree blob, root file
+system image, firmware images etc., either separate or combined.
+
+.B mkimage
+supports two different formats:
+
+The old
+.I legacy image
+format concatenates the individual parts (for example, kernel image,
+device tree blob and ramdisk image) and adds a 64 bytes header
+containing information about target architecture, operating system,
+image type, compression method, entry points, time stamp, checksums,
+etc.
+
+The new
+.I FIT (Flattened Image Tree) format
+allows for more flexibility in handling images of various types and also
+enhances integrity protection of images with stronger checksums. It also
+supports verified boot.
+
+.SH "OPTIONS"
+
+.B List image information:
+
+.TP
+.BI "\-l [" "uimage file name" "]"
+mkimage lists the information contained in the header of an existing U-Boot image.
+
+.P
+.B Create old legacy image:
+
+.TP
+.BI "\-A [" "architecture" "]"
+Set architecture. Pass \-h as the architecture to see the list of supported architectures.
+
+.TP
+.BI "\-O [" "os" "]"
+Set operating system. bootm command of u-boot changes boot method by os type.
+Pass \-h as the OS to see the list of supported OS.
+
+.TP
+.BI "\-T [" "image type" "]"
+Set image type.
+Pass \-h as the image to see the list of supported image type.
+
+.TP
+.BI "\-C [" "compression type" "]"
+Set compression type.
+Pass \-h as the compression to see the list of supported compression type.
+
+.TP
+.BI "\-a [" "load addess" "]"
+Set load address with a hex number.
+
+.TP
+.BI "\-e [" "entry point" "]"
+Set entry point with a hex number.
+
+.TP
+.BI "\-l"
+List the contents of an image.
+
+.TP
+.BI "\-n [" "image name" "]"
+Set image name to 'image name'.
+
+.TP
+.BI "\-d [" "image data file" "]"
+Use image data from 'image data file'.
+
+.TP
+.BI "\-x"
+Set XIP (execute in place) flag.
+
+.P
+.B Create FIT image:
+
+.TP
+.BI "\-c [" "comment" "]"
+Specifies a comment to be added when signing. This is typically a useful
+message which describes how the image was signed or some other useful
+information.
+
+.TP
+.BI "\-D [" "dtc options" "]"
+Provide special options to the device tree compiler that is used to
+create the image.
+
+.TP
+.BI "\-f [" "image tree source file" "]"
+Image tree source file that describes the structure and contents of the
+FIT image.
+
+.TP
+.BI "\-F"
+Indicates that an existing FIT image should be modified. No dtc
+compilation is performed and the -f flag should not be given.
+This can be used to sign images with additional keys after initial image
+creation.
+
+.TP
+.BI "\-k [" "key_directory" "]"
+Specifies the directory containing keys to use for signing. This directory
+should contain a private key file <name>.key for use with signing and a
+certificate <name>.crt (containing the public key) for use with verification.
+
+.TP
+.BI "\-K [" "key_destination" "]"
+Specifies a compiled device tree binary file (typically .dtb) to write
+public key information into. When a private key is used to sign an image,
+the corresponding public key is written into this file for for run-time
+verification. Typically the file here is the device tree binary used by
+CONFIG_OF_CONTROL in U-Boot.
+
+.TP
+.BI "\-r
+Specifies that keys used to sign the FIT are required. This means that they
+must be verified for the image to boot. Without this option, the verification
+will be optional (useful for testing but not for release).
+
+.SH EXAMPLES
+
+List image information:
+.nf
+.B mkimage -l uImage
+.fi
+.P
+Create legacy image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -A powerpc -O linux -T kernel -C gzip \\\\
+.br
+.B -a 0 -e 0 -n Linux -d vmlinux.gz uImage
+.fi
+.P
+Create FIT image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -f kernel.its kernel.itb
+.fi
+.P
+Create FIT image with compressed kernel and sign it with keys in the
+/public/signing-keys directory. Add corresponding public keys into u-boot.dtb,
+skipping those for which keys cannot be found. Also add a comment.
+.nf
+.B mkimage -f kernel.its -k /public/signing-keys -K u-boot.dtb \\\\
+-c "Kernel 3.8 image for production devices" kernel.itb
+.fi
+
+.P
+Update an existing FIT image, signing it with additional keys.
+Add corresponding public keys into u-boot.dtb. This will resign all images
+with keys that are available in the new directory. Images that request signing
+with unavailable keys are skipped.
+.nf
+.B mkimage -F -k /secret/signing-keys -K u-boot.dtb \\\\
+-c "Kernel 3.8 image for production devices" kernel.itb
+.fi
+
+.SH HOMEPAGE
+http://www.denx.de/wiki/U-Boot/WebHome
+.PP
+.SH AUTHOR
+This manual page was written by Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+and Wolfgang Denk <wd@denx.de>. It was updated for image signing by
+Simon Glass <sjg@chromium.org>.
diff --git a/marvell/uboot/doc/uImage.FIT/command_syntax_extensions.txt b/marvell/uboot/doc/uImage.FIT/command_syntax_extensions.txt
new file mode 100644
index 0000000..6c99b1c
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/command_syntax_extensions.txt
@@ -0,0 +1,191 @@
+Command syntax extensions for the new uImage format
+===================================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+With the introduction of the new uImage format, bootm command (and other
+commands as well) have to understand new syntax of the arguments. This is
+necessary in order to specify objects contained in the new uImage, on which
+bootm has to operate. This note attempts to first summarize bootm usage
+scenarios, and then introduces new argument syntax.
+
+
+bootm usage scenarios
+---------------------
+
+Below is a summary of bootm usage scenarios, focused on booting a PowerPC
+Linux kernel. The purpose of the following list is to document a complete list
+of supported bootm usages.
+
+Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
+i.e., without passing the Flattened Device Tree (FDT), and new way, where the
+kernel is passed a pointer to the FDT. The boot method is indicated for each
+scenario.
+
+
+1. bootm boot image at the current address, equivalent to 2,3,8
+
+Old uImage:
+2. bootm <addr1> /* single image at <addr1> */
+3. bootm <addr1> /* multi-image at <addr1> */
+4. bootm <addr1> - /* multi-image at <addr1> */
+5. bootm <addr1> <addr2> /* single image at <addr1> */
+6. bootm <addr1> <addr2> <addr3> /* single image at <addr1> */
+7. bootm <addr1> - <addr3> /* single image at <addr1> */
+
+New uImage:
+8. bootm <addr1>
+9. bootm [<addr1>]:<subimg1>
+10. bootm [<addr1>]#<conf>
+11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
+12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
+13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
+14. bootm [<addr1>]:<subimg1> - [<addr3>]:<subimg3>
+15. bootm [<addr1>]:<subimg1> - <addr3>
+
+
+Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
+the current image address.
+- boot method: see cases 2,3,8
+
+Ad. 2. Boot kernel image located at <addr1>.
+- boot method: non-FDT
+
+Ad. 3. First and second components of the image at <addr1> are assumed to be a
+kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
+with the ramdisk from the image.
+- boot method: depends on the number of components at <addr1>, and on whether
+ U-Boot is compiled with OF support:
+
+ | 2 components | 3 components |
+ | (kernel, initrd) | (kernel, initrd, fdt) |
+---------------------------------------------------------------------
+#ifdef CONFIG_OF_* | non-FDT | FDT |
+#ifndef CONFIG_OF_* | non-FDT | non-FDT |
+
+Ad. 4. Similar to case 3, but the kernel is booted without initrd. Second
+component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
+- boot method: see case 3
+
+Ad. 5. Boot kernel image located at <addr1> with initrd loaded with ramdisk
+from the image at <addr2>.
+- boot method: non-FDT
+
+Ad. 6. <addr1> is the address of a kernel image, <addr2> is the address of a
+ramdisk image, and <addr3> is the address of a FDT binary blob. Kernel is
+booted with initrd loaded with ramdisk from the image at <addr2>.
+- boot method: FDT
+
+Ad. 7. <addr1> is the address of a kernel image and <addr3> is the address of
+a FDT binary blob. Kernel is booted without initrd.
+- boot method: FDT
+
+Ad. 8. Image at <addr1> is assumed to contain a default configuration, which
+is booted.
+- boot method: FDT or non-FDT, depending on whether the default configuration
+ defines FDT
+
+Ad. 9. Similar to case 2: boot kernel stored in <subimg1> from the image at
+address <addr1>.
+- boot method: non-FDT
+
+Ad. 10. Boot configuration <conf> from the image at <addr1>.
+- boot method: FDT or non-FDT, depending on whether the configuration given
+ defines FDT
+
+Ad. 11. Equivalent to case 5: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>.
+- boot method: non-FDT
+
+Ad. 12. Equivalent to case 6: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
+- boot method: FDT
+
+Ad. 13. Similar to case 12, the difference being that <addr3> is the address
+of FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+Ad. 14. Equivalent to case 7: boot kernel stored in <subimg1> from the image
+at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
+<addr3>.
+- boot method: FDT
+
+Ad. 15. Similar to case 14, the difference being that <addr3> is the address
+of the FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+
+New uImage argument syntax
+--------------------------
+
+New uImage support introduces two new forms for bootm arguments, with the
+following syntax:
+
+- new uImage sub-image specification
+<addr>:<sub-image unit_name>
+
+- new uImage configuration specification
+<addr>#<configuration unit_name>
+
+
+Examples:
+
+- boot kernel "kernel@1" stored in a new uImage located at 200000:
+bootm 200000:kernel@1
+
+- boot configuration "cfg@1" from a new uImage located at 200000:
+bootm 200000#cfg@1
+
+- boot "kernel@1" from a new uImage at 200000 with initrd "ramdisk@2" found in
+ some other new uImage stored at address 800000:
+bootm 200000:kernel@1 800000:ramdisk@2
+
+- boot "kernel@2" from a new uImage at 200000, with initrd "ramdisk@1" and FDT
+ "fdt@1", both stored in some other new uImage located at 800000:
+bootm 200000:kernel@1 800000:ramdisk@1 800000:fdt@1
+
+- boot kernel "kernel@2" with initrd "ramdisk@2", both stored in a new uImage
+ at address 200000, with a raw FDT blob stored at address 600000:
+bootm 200000:kernel@2 200000:ramdisk@2 600000
+
+- boot kernel "kernel@2" from new uImage at 200000 with FDT "fdt@1" from the
+ same new uImage:
+bootm 200000:kernel@2 - 200000:fdt@1
+
+
+Note on current image address
+-----------------------------
+
+When bootm is called without arguments, the image at current image address is
+booted. The current image address is the address set most recently by a load
+command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example, consider
+the following commands:
+
+tftp 200000 /tftpboot/kernel
+bootm
+Last command is equivalent to:
+bootm 200000
+
+In case of the new uImage argument syntax, the address portion of any argument
+can be omitted. If <addr3> is omitted, then it is assumed that image at
+<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
+image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
+current image address is to be used. For example, consider the following
+commands:
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel@1
+Last command is equivalent to:
+bootm 200000:kernel@1
+
+tftp 200000 /tftpboot/uImage
+bootm 400000:kernel@1 :ramdisk@1
+Last command is equivalent to:
+bootm 400000:kernel@1 400000:ramdisk@1
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel@1 400000:ramdisk@1 :fdt@1
+Last command is equivalent to:
+bootm 200000:kernel@1 400000:ramdisk@1 400000:fdt@1
diff --git a/marvell/uboot/doc/uImage.FIT/howto.txt b/marvell/uboot/doc/uImage.FIT/howto.txt
new file mode 100644
index 0000000..526be55
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/howto.txt
@@ -0,0 +1,297 @@
+How to use images in the new image format
+=========================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+
+Overview
+--------
+
+The new uImage format allows more flexibility in handling images of various
+types (kernel, ramdisk, etc.), it also enhances integrity protection of images
+with sha1 and md5 checksums.
+
+Two auxiliary tools are needed on the development host system in order to
+create an uImage in the new format: mkimage and dtc, although only one
+(mkimage) is invoked directly. dtc is called from within mkimage and operates
+behind the scenes, but needs to be present in the $PATH nevertheless. It is
+important that the dtc used has support for binary includes -- refer to
+www.jdl.com for its latest version. mkimage (together with dtc) takes as input
+an image source file, which describes the contents of the image and defines
+its various properties used during booting. By convention, image source file
+has the ".its" extension, also, the details of its format are given in
+doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in
+the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
+form of paths to appropriate data files. The outcome of the image creation
+process is a binary file (by convention with the ".itb" extension) that
+contains all the referenced data (kernel, ramdisk, etc.) and other information
+needed by U-Boot to handle the uImage properly. The uImage file is then
+transferred to the target (e.g., via tftp) and booted using the bootm command.
+
+To summarize the prerequisites needed for new uImage creation:
+- mkimage
+- dtc (with support for binary includes)
+- image source file (*.its)
+- image data file(s)
+
+
+Here's a graphical overview of the image creation and booting process:
+
+image source file mkimage + dtc transfer to target
+ + ---------------> image file --------------------> bootm
+image data file(s)
+
+
+Example 1 -- old-style (non-FDT) kernel booting
+-----------------------------------------------
+
+Consider a simple scenario, where a PPC Linux kernel built from sources on the
+development host is to be booted old-style (non-FDT) by U-Boot on an embedded
+target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
+contains a gzip-compressed PPC Linux kernel (the only data file in this case).
+The uImage can be produced using the image source file
+doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
+in the current working directory; if desired, an alternative path can be
+specified in the kernel.its file). Here's how to create the image and inspect
+its contents:
+
+[on the host system]
+$ mkimage -f kernel.its kernel.itb
+DTC: dts->dtb on file "kernel.its"
+$
+$ mkimage -l kernel.itb
+FIT description: Simple image with single Linux kernel
+Created: Tue Mar 11 17:26:15 2008
+ Image 0 (kernel@1)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Size: 943347 Bytes = 921.24 kB = 0.90 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Default Configuration: 'config@1'
+ Configuration 0 (config@1)
+ Description: Boot Linux kernel
+ Kernel: kernel@1
+
+
+The resulting image file kernel.itb can be now transferred to the target,
+inspected and booted (note that first three U-Boot commands below are shown
+for completeness -- they are part of the standard booting procedure and not
+specific to the new image format).
+
+[on the target system]
+=> print nfsargs
+nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
+=> print addip
+addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
+=> run nfsargs addip
+=> tftp 900000 /path/to/tftp/location/kernel.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel.itb'.
+Load address: 0x900000
+Loading: #################################################################
+done
+Bytes transferred = 944464 (e6950 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+ FIT image found
+ FIT description: Simple image with single Linux kernel
+ Created: 2008-03-11 16:26:15 UTC
+ Image 0 (kernel@1)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000e0
+ Data Size: 943347 Bytes = 921.2 kB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Default Configuration: 'config@1'
+ Configuration 0 (config@1)
+ Description: Boot Linux kernel
+ Kernel: kernel@1
+
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+ Using 'config@1' configuration
+ Trying 'kernel@1' kernel subimage
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000e0
+ Data Size: 943347 Bytes = 921.2 kB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Uncompressing Kernel Image ... OK
+Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
+Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
+On node 0 totalpages: 65536
+zone(0): 65536 pages.
+zone(1): 0 pages.
+zone(2): 0 pages.
+Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
+Calibrating delay loop... 307.20 BogoMIPS
+
+
+Example 2 -- new-style (FDT) kernel booting
+-------------------------------------------
+
+Consider another simple scenario, where a PPC Linux kernel is to be booted
+new-style, i.e., with a FDT blob. In this case there are two prerequisite data
+files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
+be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
+(note again, that both prerequisite data files are assumed to be present in
+the current working directory -- image source file kernel_fdt.its can be
+modified to take the files from some other location if needed):
+
+[on the host system]
+$ mkimage -f kernel_fdt.its kernel_fdt.itb
+DTC: dts->dtb on file "kernel_fdt.its"
+$
+$ mkimage -l kernel_fdt.itb
+FIT description: Simple image with single Linux kernel and FDT blob
+Created: Tue Mar 11 16:29:22 2008
+ Image 0 (kernel@1)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Size: 1092037 Bytes = 1066.44 kB = 1.04 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Image 1 (fdt@1)
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Size: 16384 Bytes = 16.00 kB = 0.02 MB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Default Configuration: 'conf@1'
+ Configuration 0 (conf@1)
+ Description: Boot Linux kernel with FDT blob
+ Kernel: kernel@1
+ FDT: fdt@1
+
+
+The resulting image file kernel_fdt.itb can be now transferred to the target,
+inspected and booted:
+
+[on the target system]
+=> tftp 900000 /path/to/tftp/location/kernel_fdt.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel_fdt.itb'.
+Load address: 0x900000
+Loading: #################################################################
+ ###########
+done
+Bytes transferred = 1109776 (10ef10 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+ FIT image found
+ FIT description: Simple image with single Linux kernel and FDT blob
+ Created: 2008-03-11 15:29:22 UTC
+ Image 0 (kernel@1)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000ec
+ Data Size: 1092037 Bytes = 1 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Image 1 (fdt@1)
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x00a0abdc
+ Data Size: 16384 Bytes = 16 kB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Default Configuration: 'conf@1'
+ Configuration 0 (conf@1)
+ Description: Boot Linux kernel with FDT blob
+ Kernel: kernel@1
+ FDT: fdt@1
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+ Using 'conf@1' configuration
+ Trying 'kernel@1' kernel subimage
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000ec
+ Data Size: 1092037 Bytes = 1 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Uncompressing Kernel Image ... OK
+## Flattened Device Tree from FIT Image at 00900000
+ Using 'conf@1' configuration
+ Trying 'fdt@1' FDT blob subimage
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x00a0abdc
+ Data Size: 16384 Bytes = 16 kB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Booting using the fdt blob at 0xa0abdc
+ Loading Device Tree to 007fc000, end 007fffff ... OK
+[ 0.000000] Using lite5200 machine description
+[ 0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
+
+
+Example 3 -- advanced booting
+-----------------------------
+
+Refer to doc/uImage.FIT/multi.its for an image source file that allows more
+sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).
diff --git a/marvell/uboot/doc/uImage.FIT/kernel.its b/marvell/uboot/doc/uImage.FIT/kernel.its
new file mode 100644
index 0000000..ef3ab8f
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/kernel.its
@@ -0,0 +1,37 @@
+/*
+ * Simple U-boot uImage source file containing a single kernel
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Simple image with single Linux kernel";
+ #address-cells = <1>;
+
+ images {
+ kernel@1 {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "crc32";
+ };
+ hash@2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "config@1";
+ config@1 {
+ description = "Boot Linux kernel";
+ kernel = "kernel@1";
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/kernel_fdt.its b/marvell/uboot/doc/uImage.FIT/kernel_fdt.its
new file mode 100644
index 0000000..7e940d2
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/kernel_fdt.its
@@ -0,0 +1,51 @@
+/*
+ * Simple U-boot uImage source file containing a single kernel and FDT blob
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Simple image with single Linux kernel and FDT blob";
+ #address-cells = <1>;
+
+ images {
+ kernel@1 {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "crc32";
+ };
+ hash@2 {
+ algo = "sha1";
+ };
+ };
+ fdt@1 {
+ description = "Flattened Device Tree blob";
+ data = /incbin/("./target.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ hash@1 {
+ algo = "crc32";
+ };
+ hash@2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ description = "Boot Linux kernel with FDT blob";
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/multi.its b/marvell/uboot/doc/uImage.FIT/multi.its
new file mode 100644
index 0000000..881b749
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/multi.its
@@ -0,0 +1,133 @@
+/*
+ * U-boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Various kernels, ramdisks and FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel@1 {
+ description = "vanilla-2.6.23";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "md5";
+ };
+ hash@2 {
+ algo = "sha1";
+ };
+ };
+
+ kernel@2 {
+ description = "2.6.23-denx";
+ data = /incbin/("./2.6.23-denx.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+
+ kernel@3 {
+ description = "2.4.25-denx";
+ data = /incbin/("./2.4.25-denx.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "md5";
+ };
+ };
+
+ ramdisk@1 {
+ description = "eldk-4.2-ramdisk";
+ data = /incbin/("./eldk-4.2-ramdisk");
+ type = "ramdisk";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+
+ ramdisk@2 {
+ description = "eldk-3.1-ramdisk";
+ data = /incbin/("./eldk-3.1-ramdisk");
+ type = "ramdisk";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash@1 {
+ algo = "crc32";
+ };
+ };
+
+ fdt@1 {
+ description = "tqm5200-fdt";
+ data = /incbin/("./tqm5200.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ hash@1 {
+ algo = "crc32";
+ };
+ };
+
+ fdt@2 {
+ description = "tqm5200s-fdt";
+ data = /incbin/("./tqm5200s.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ load = <00700000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+
+ };
+
+ configurations {
+ default = "config@1";
+
+ config@1 {
+ description = "tqm5200 vanilla-2.6.23 configuration";
+ kernel = "kernel@1";
+ ramdisk = "ramdisk@1";
+ fdt = "fdt@1";
+ };
+
+ config@2 {
+ description = "tqm5200s denx-2.6.23 configuration";
+ kernel = "kernel@2";
+ ramdisk = "ramdisk@1";
+ fdt = "fdt@2";
+ };
+
+ config@3 {
+ description = "tqm5200s denx-2.4.25 configuration";
+ kernel = "kernel@3";
+ ramdisk = "ramdisk@2";
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/sign-configs.its b/marvell/uboot/doc/uImage.FIT/sign-configs.its
new file mode 100644
index 0000000..3c17f04
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/sign-configs.its
@@ -0,0 +1,45 @@
+/dts-v1/;
+
+/ {
+ description = "Chrome OS kernel image with one or more FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel@1 {
+ data = /incbin/("test-kernel.bin");
+ type = "kernel_noload";
+ arch = "sandbox";
+ os = "linux";
+ compression = "lzo";
+ load = <0x4>;
+ entry = <0x8>;
+ kernel-version = <1>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+ fdt@1 {
+ description = "snow";
+ data = /incbin/("sandbox-kernel.dtb");
+ type = "flat_dt";
+ arch = "sandbox";
+ compression = "none";
+ fdt-version = <1>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+ };
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ signature@1 {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "fdt", "kernel";
+ };
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/sign-images.its b/marvell/uboot/doc/uImage.FIT/sign-images.its
new file mode 100644
index 0000000..f69326a
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/sign-images.its
@@ -0,0 +1,42 @@
+/dts-v1/;
+
+/ {
+ description = "Chrome OS kernel image with one or more FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel@1 {
+ data = /incbin/("test-kernel.bin");
+ type = "kernel_noload";
+ arch = "sandbox";
+ os = "linux";
+ compression = "none";
+ load = <0x4>;
+ entry = <0x8>;
+ kernel-version = <1>;
+ signature@1 {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ };
+ };
+ fdt@1 {
+ description = "snow";
+ data = /incbin/("sandbox-kernel.dtb");
+ type = "flat_dt";
+ arch = "sandbox";
+ compression = "none";
+ fdt-version = <1>;
+ signature@1 {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ };
+ };
+ };
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/signature.txt b/marvell/uboot/doc/uImage.FIT/signature.txt
new file mode 100644
index 0000000..bc9f3fa
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/signature.txt
@@ -0,0 +1,382 @@
+U-Boot FIT Signature Verification
+=================================
+
+Introduction
+------------
+FIT supports hashing of images so that these hashes can be checked on
+loading. This protects against corruption of the image. However it does not
+prevent the substitution of one image for another.
+
+The signature feature allows the hash to be signed with a private key such
+that it can be verified using a public key later. Provided that the private
+key is kept secret and the public key is stored in a non-volatile place,
+any image can be verified in this way.
+
+See verified-boot.txt for more general information on verified boot.
+
+
+Concepts
+--------
+Some familiarity with public key cryptography is assumed in this section.
+
+The procedure for signing is as follows:
+
+ - hash an image in the FIT
+ - sign the hash with a private key to produce a signature
+ - store the resulting signature in the FIT
+
+The procedure for verification is:
+
+ - read the FIT
+ - obtain the public key
+ - extract the signature from the FIT
+ - hash the image from the FIT
+ - verify (with the public key) that the extracted signature matches the
+ hash
+
+The signing is generally performed by mkimage, as part of making a firmware
+image for the device. The verification is normally done in U-Boot on the
+device.
+
+
+Algorithms
+----------
+In principle any suitable algorithm can be used to sign and verify a hash.
+At present only one class of algorithms is supported: SHA1 hashing with RSA.
+This works by hashing the image to produce a 20-byte hash.
+
+While it is acceptable to bring in large cryptographic libraries such as
+openssl on the host side (e.g. mkimage), it is not desirable for U-Boot.
+For the run-time verification side, it is important to keep code and data
+size as small as possible.
+
+For this reason the RSA image verification uses pre-processed public keys
+which can be used with a very small amount of code - just some extraction
+of data from the FDT and exponentiation mod n. Code size impact is a little
+under 5KB on Tegra Seaboard, for example.
+
+It is relatively straightforward to add new algorithms if required. If
+another RSA variant is needed, then it can be added to the table in
+image-sig.c. If another algorithm is needed (such as DSA) then it can be
+placed alongside rsa.c, and its functions added to the table in image-sig.c
+also.
+
+
+Creating an RSA key and certificate
+-----------------------------------
+To create a new public key, size 2048 bits:
+
+$ openssl genrsa -F4 -out keys/dev.key 2048
+
+To create a certificate for this:
+
+$ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+If you like you can look at the public key also:
+
+$ openssl rsa -in keys/dev.key -pubout
+
+
+Device Tree Bindings
+--------------------
+The following properties are required in the FIT's signature node(s) to
+allow thes signer to operate. These should be added to the .its file.
+Signature nodes sit at the same level as hash nodes and are called
+signature@1, signature@2, etc.
+
+- algo: Algorithm name (e.g. "sha1,rs2048")
+
+- key-name-hint: Name of key to use for signing. The keys will normally be in
+a single directory (parameter -k to mkimage). For a given key <name>, its
+private key is stored in <name>.key and the certificate is stored in
+<name>.crt.
+
+When the image is signed, the following properties are added (mandatory):
+
+- value: The signature data (e.g. 256 bytes for 2048-bit RSA)
+
+When the image is signed, the following properties are optional:
+
+- timestamp: Time when image was signed (standard Unix time_t format)
+
+- signer-name: Name of the signer (e.g. "mkimage")
+
+- signer-version: Version string of the signer (e.g. "2013.01")
+
+- comment: Additional information about the signer or image
+
+For config bindings (see Signed Configurations below), the following
+additional properties are optional:
+
+- sign-images: A list of images to sign, each being a property of the conf
+node that contains then. The default is "kernel,fdt" which means that these
+two images will be looked up in the config and signed if present.
+
+For config bindings, these properties are added by the signer:
+
+- hashed-nodes: A list of nodes which were hashed by the signer. Each is
+ a string - the full path to node. A typical value might be:
+
+ hashed-nodes = "/", "/configurations/conf@1", "/images/kernel@1",
+ "/images/kernel@1/hash@1", "/images/fdt@1",
+ "/images/fdt@1/hash@1";
+
+- hashed-strings: The start and size of the string region of the FIT that
+ was hashed
+
+Example: See sign-images.its for an example image tree source file and
+sign-configs.its for config signing.
+
+
+Public Key Storage
+------------------
+In order to verify an image that has been signed with a public key we need to
+have a trusted public key. This cannot be stored in the signed image, since
+it would be easy to alter. For this implementation we choose to store the
+public key in U-Boot's control FDT (using CONFIG_OF_CONTROL).
+
+Public keys should be stored as sub-nodes in a /signature node. Required
+properties are:
+
+- algo: Algorithm name (e.g. "sha1,rs2048")
+
+Optional properties are:
+
+- key-name-hint: Name of key used for signing. This is only a hint since it
+is possible for the name to be changed. Verification can proceed by checking
+all available signing keys until one matches.
+
+- required: If present this indicates that the key must be verified for the
+image / configuration to be considered valid. Only required keys are
+normally verified by the FIT image booting algorithm. Valid values are
+"image" to force verification of all images, and "conf" to force verfication
+of the selected configuration (which then relies on hashes in the images to
+verify those).
+
+Each signing algorithm has its own additional properties.
+
+For RSA the following are mandatory:
+
+- rsa,num-bits: Number of key bits (e.g. 2048)
+- rsa,modulus: Modulus (N) as a big-endian multi-word integer
+- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
+- rsa,n0-inverse: -1 / modulus[0] mod 2^32
+
+
+Signed Configurations
+---------------------
+While signing images is useful, it does not provide complete protection
+against several types of attack. For example, it it possible to create a
+FIT with the same signed images, but with the configuration changed such
+that a different one is selected (mix and match attack). It is also possible
+to substitute a signed image from an older FIT version into a newer FIT
+(roll-back attack).
+
+As an example, consider this FIT:
+
+/ {
+ images {
+ kernel@1 {
+ data = <data for kernel1>
+ signature@1 {
+ algo = "sha1,rsa2048";
+ value = <...kernel signature 1...>
+ };
+ };
+ kernel@2 {
+ data = <data for kernel2>
+ signature@1 {
+ algo = "sha1,rsa2048";
+ value = <...kernel signature 2...>
+ };
+ };
+ fdt@1 {
+ data = <data for fdt1>;
+ signature@1 {
+ algo = "sha1,rsa2048";
+ vaue = <...fdt signature 1...>
+ };
+ };
+ fdt@2 {
+ data = <data for fdt2>;
+ signature@1 {
+ algo = "sha1,rsa2048";
+ vaue = <...fdt signature 2...>
+ };
+ };
+ };
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ };
+ conf@1 {
+ kernel = "kernel@2";
+ fdt = "fdt@2";
+ };
+ };
+};
+
+Since both kernels are signed it is easy for an attacker to add a new
+configuration 3 with kernel 1 and fdt 2:
+
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ };
+ conf@1 {
+ kernel = "kernel@2";
+ fdt = "fdt@2";
+ };
+ conf@3 {
+ kernel = "kernel@1";
+ fdt = "fdt@2";
+ };
+ };
+
+With signed images, nothing protects against this. Whether it gains an
+advantage for the attacker is debatable, but it is not secure.
+
+To solved this problem, we support signed configurations. In this case it
+is the configurations that are signed, not the image. Each image has its
+own hash, and we include the hash in the configuration signature.
+
+So the above example is adjusted to look like this:
+
+/ {
+ images {
+ kernel@1 {
+ data = <data for kernel1>
+ hash@1 {
+ algo = "sha1";
+ value = <...kernel hash 1...>
+ };
+ };
+ kernel@2 {
+ data = <data for kernel2>
+ hash@1 {
+ algo = "sha1";
+ value = <...kernel hash 2...>
+ };
+ };
+ fdt@1 {
+ data = <data for fdt1>;
+ hash@1 {
+ algo = "sha1";
+ value = <...fdt hash 1...>
+ };
+ };
+ fdt@2 {
+ data = <data for fdt2>;
+ hash@1 {
+ algo = "sha1";
+ value = <...fdt hash 2...>
+ };
+ };
+ };
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ kernel = "kernel@1";
+ fdt = "fdt@1";
+ signature@1 {
+ algo = "sha1,rsa2048";
+ value = <...conf 1 signature...>;
+ };
+ };
+ conf@2 {
+ kernel = "kernel@2";
+ fdt = "fdt@2";
+ signature@1 {
+ algo = "sha1,rsa2048";
+ value = <...conf 1 signature...>;
+ };
+ };
+ };
+};
+
+
+You can see that we have added hashes for all images (since they are no
+longer signed), and a signature to each configuration. In the above example,
+mkimage will sign configurations/conf@1, the kernel and fdt that are
+pointed to by the configuration (/images/kernel@1, /images/kernel@1/hash@1,
+/images/fdt@1, /images/fdt@1/hash@1) and the root structure of the image
+(so that it isn't possible to add or remove root nodes). The signature is
+written into /configurations/conf@1/signature@1/value. It can easily be
+verified later even if the FIT has been signed with other keys in the
+meantime.
+
+
+Verification
+------------
+FITs are verified when loaded. After the configuration is selected a list
+of required images is produced. If there are 'required' public keys, then
+each image must be verified against those keys. This means that every image
+that might be used by the target needs to be signed with 'required' keys.
+
+This happens automatically as part of a bootm command when FITs are used.
+
+
+Enabling FIT Verification
+-------------------------
+In addition to the options to enable FIT itself, the following CONFIGs must
+be enabled:
+
+CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs
+CONFIG_RSA - enable RSA algorithm for signing
+
+
+Testing
+-------
+An easy way to test signing and verfication is to use the test script
+provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
+of U-Boot which runs under Linux) to show the operation of a 'bootm'
+command loading and verifying images.
+
+A sample run is show below:
+
+$ make O=sandbox sandbox_config
+$ make O=sandbox
+$ O=sandbox ./test/vboot/vboot_test.sh
+Simple Verified Boot Test
+=========================
+
+Please see doc/uImage.FIT/verified-boot.txt for more information
+
+Build keys
+Build FIT with signed images
+Test Verified Boot Run: unsigned signatures:: OK
+Sign images
+Test Verified Boot Run: signed images: OK
+Build FIT with signed configuration
+Test Verified Boot Run: unsigned config: OK
+Sign images
+Test Verified Boot Run: signed config: OK
+
+Test passed
+
+
+Future Work
+-----------
+- Roll-back protection using a TPM is done using the tpm command. This can
+be scripted, but we might consider a default way of doing this, built into
+bootm.
+
+
+Possible Future Work
+--------------------
+- Add support for other RSA/SHA variants, such as rsa4096,sha512.
+- Other algorithms besides RSA
+- More sandbox tests for failure modes
+- Passwords for keys/certificates
+- Perhaps implement OAEP
+- Enhance bootm to permit scripted signature verification (so that a script
+can verify an image but not actually boot it)
+
+
+Simon Glass
+sjg@chromium.org
+1-1-13
diff --git a/marvell/uboot/doc/uImage.FIT/source_file_format.txt b/marvell/uboot/doc/uImage.FIT/source_file_format.txt
new file mode 100644
index 0000000..9ed6f65
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/source_file_format.txt
@@ -0,0 +1,261 @@
+U-boot new uImage source file format (bindings definition)
+==========================================================
+
+Author: Marian Balakowicz <m8@semihalf.com>
+
+1) Introduction
+---------------
+
+Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
+booting method which requires that hardware description is available to the
+kernel in the form of Flattened Device Tree.
+
+Booting with a Flattened Device Tree is much more flexible and is intended to
+replace direct passing of 'struct bd_info' which was used to boot pre-FDT
+kernels.
+
+However, U-boot needs to support both techniques to provide backward
+compatibility for platforms which are not FDT ready. Number of elements
+playing role in the booting process has increased and now includes the FDT
+blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
+in the system memory and passed to bootm as a arguments. Some of them may be
+missing: FDT is not present for legacy platforms, ramdisk is always optional.
+Additionally, old uImage format has been extended to support multi sub-images
+but the support is limited by simple format of the legacy uImage structure.
+Single binary header 'struct image_header' is not flexible enough to cover all
+possible scenarios.
+
+All those factors combined clearly show that there is a need for new, more
+flexible, multi component uImage format.
+
+
+2) New uImage format assumptions
+--------------------------------
+
+a) Implementation
+
+Libfdt has been selected for the new uImage format implementation as (1) it
+provides needed functionality, (2) is actively maintained and developed and
+(3) increases code reuse as it is already part of the U-boot source tree.
+
+b) Terminology
+
+This document defines new uImage structure by providing FDT bindings for new
+uImage internals. Bindings are defined from U-boot perspective, i.e. describe
+final form of the uImage at the moment when it reaches U-boot. User
+perspective may be simpler, as some of the properties (like timestamps and
+hashes) will need to be filled in automatically by the U-boot mkimage tool.
+
+To avoid confusion with the kernel FDT the following naming convention is
+proposed for the new uImage format related terms:
+
+FIT - Flattened uImage Tree
+
+FIT is formally a flattened device tree (in the libfdt meaning), which
+conforms to bindings defined in this document.
+
+.its - image tree source
+.itb - image tree blob
+
+c) Image building procedure
+
+The following picture shows how the new uImage is prepared. Input consists of
+image source file (.its) and a set of data files. Image is created with the
+help of standard U-boot mkimage tool which in turn uses dtc (device tree
+compiler) to produce image tree blob (.itb). Resulting .itb file is the
+actual binary of a new uImage.
+
+
+tqm5200.its
++
+vmlinux.bin.gz mkimage + dtc xfer to target
+eldk-4.2-ramdisk --------------> tqm5200.itb --------------> bootm
+tqm5200.dtb /|\
+... |
+ 'new uImage'
+
+ - create .its file, automatically filled-in properties are omitted
+ - call mkimage tool on a .its file
+ - mkimage calls dtc to create .itb image and assures that
+ missing properties are added
+ - .itb (new uImage) is uploaded onto the target and used therein
+
+
+d) Unique identifiers
+
+To identify FIT sub-nodes representing images, hashes, configurations (which
+are defined in the following sections), the "unit name" of the given sub-node
+is used as it's identifier as it assures uniqueness without additional
+checking required.
+
+
+3) Root node properties
+-----------------------
+
+Root node of the uImage Tree should have the following layout:
+
+/ o image-tree
+ |- description = "image description"
+ |- timestamp = <12399321>
+ |- #address-cells = <1>
+ |
+ o images
+ | |
+ | o img@1 {...}
+ | o img@2 {...}
+ | ...
+ |
+ o configurations
+ |- default = "cfg@1"
+ |
+ o cfg@1 {...}
+ o cfg@2 {...}
+ ...
+
+
+ Optional property:
+ - description : Textual description of the uImage
+
+ Mandatory property:
+ - timestamp : Last image modification time being counted in seconds since
+ 1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
+
+ Conditionally mandatory property:
+ - #address-cells : Number of 32bit cells required to represent entry and
+ load addresses supplied within sub-image nodes. May be omitted when no
+ entry or load addresses are used.
+
+ Mandatory node:
+ - images : This node contains a set of sub-nodes, each of them representing
+ single component sub-image (like kernel, ramdisk, etc.). At least one
+ sub-image is required.
+
+ Optional node:
+ - configurations : Contains a set of available configuration nodes and
+ defines a default configuration.
+
+
+4) '/images' node
+-----------------
+
+This node is a container node for component sub-image nodes. Each sub-node of
+the '/images' node should have the following layout:
+
+ o image@1
+ |- description = "component sub-image description"
+ |- data = /incbin/("path/to/data/file.bin")
+ |- type = "sub-image type name"
+ |- arch = "ARCH name"
+ |- os = "OS name"
+ |- compression = "compression name"
+ |- load = <00000000>
+ |- entry = <00000000>
+ |
+ o hash@1 {...}
+ o hash@2 {...}
+ ...
+
+ Mandatory properties:
+ - description : Textual description of the component sub-image
+ - type : Name of component sub-image type, supported types are:
+ "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
+ "flat_dt".
+ - data : Path to the external file which contains this node's binary data.
+ - compression : Compression used by included data. Supported compressions
+ are "gzip" and "bzip2". If no compression is used compression property
+ should be set to "none".
+
+ Conditionally mandatory property:
+ - os : OS name, mandatory for type="kernel", valid OS names are: "openbsd",
+ "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", "solaris", "irix",
+ "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx", "u_boot",
+ "rtems", "unity", "integrity".
+ - arch : Architecture name, mandatory for types: "standalone", "kernel",
+ "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
+ "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
+ "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200".
+ - entry : entry point address, address size is determined by
+ '#address-cells' property of the root node. Mandatory for for types:
+ "standalone" and "kernel".
+ - load : load address, address size is determined by '#address-cells'
+ property of the root node. Mandatory for types: "standalone" and "kernel".
+
+ Optional nodes:
+ - hash@1 : Each hash sub-node represents separate hash or checksum
+ calculated for node's data according to specified algorithm.
+
+
+5) Hash nodes
+-------------
+
+o hash@1
+ |- algo = "hash or checksum algorithm name"
+ |- value = [hash or checksum value]
+
+ Mandatory properties:
+ - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
+ - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
+ long.
+
+
+6) '/configurations' node
+-------------------------
+
+The 'configurations' node is optional. If present, it allows to create a
+convenient, labeled boot configurations, which combine together kernel images
+with their ramdisks and fdt blobs.
+
+The 'configurations' node has has the following structure:
+
+o configurations
+ |- default = "default configuration sub-node unit name"
+ |
+ o config@1 {...}
+ o config@2 {...}
+ ...
+
+
+ Optional property:
+ - default : Selects one of the configuration sub-nodes as a default
+ configuration.
+
+ Mandatory nodes:
+ - configuration-sub-node-unit-name : At least one of the configuration
+ sub-nodes is required.
+
+
+7) Configuration nodes
+----------------------
+
+Each configuration has the following structure:
+
+o config@1
+ |- description = "configuration description"
+ |- kernel = "kernel sub-node unit name"
+ |- ramdisk = "ramdisk sub-node unit name"
+ |- fdt = "fdt sub-node unit-name"
+
+
+ Mandatory properties:
+ - description : Textual configuration description.
+ - kernel : Unit name of the corresponding kernel image (image sub-node of a
+ "kernel" type).
+
+ Optional properties:
+ - ramdisk : Unit name of the corresponding ramdisk image (component image
+ node of a "ramdisk" type).
+ - fdt : Unit name of the corresponding fdt blob (component image node of a
+ "fdt type").
+
+The FDT blob is required to properly boot FDT based kernel, so the minimal
+configuration for 2.6 FDT kernel is (kernel, fdt) pair.
+
+Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
+'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
+not* be specified in a configuration node.
+
+
+8) Examples
+-----------
+
+Please see doc/uImage.FIT/*.its for actual image source files.
diff --git a/marvell/uboot/doc/uImage.FIT/update3.its b/marvell/uboot/doc/uImage.FIT/update3.its
new file mode 100644
index 0000000..a6eaef6
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/update3.its
@@ -0,0 +1,44 @@
+/*
+ * Example Automatic software update file.
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Automatic software updates: kernel, ramdisk, FDT";
+ #address-cells = <1>;
+
+ images {
+ update@1 {
+ description = "Linux kernel binary";
+ data = /incbin/("./vmlinux.bin.gz");
+ compression = "none";
+ type = "firmware";
+ load = <FF700000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+ update@2 {
+ description = "Ramdisk image";
+ data = /incbin/("./ramdisk_image.gz");
+ compression = "none";
+ type = "firmware";
+ load = <FF8E0000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+
+ update@3 {
+ description = "FDT blob";
+ data = /incbin/("./blob.fdt");
+ compression = "none";
+ type = "firmware";
+ load = <FFAC0000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/update_uboot.its b/marvell/uboot/doc/uImage.FIT/update_uboot.its
new file mode 100644
index 0000000..846723e
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/update_uboot.its
@@ -0,0 +1,24 @@
+/*
+ * Automatic software update for U-Boot
+ * Make sure the flashing addresses ('load' prop) is correct for your board!
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Automatic U-Boot update";
+ #address-cells = <1>;
+
+ images {
+ update@1 {
+ description = "U-Boot binary";
+ data = /incbin/("./u-boot.bin");
+ compression = "none";
+ type = "firmware";
+ load = <FFFC0000>;
+ hash@1 {
+ algo = "sha1";
+ };
+ };
+ };
+};
diff --git a/marvell/uboot/doc/uImage.FIT/verified-boot.txt b/marvell/uboot/doc/uImage.FIT/verified-boot.txt
new file mode 100644
index 0000000..3c83fbc
--- /dev/null
+++ b/marvell/uboot/doc/uImage.FIT/verified-boot.txt
@@ -0,0 +1,104 @@
+U-Boot Verified Boot
+====================
+
+Introduction
+------------
+Verified boot here means the verification of all software loaded into a
+machine during the boot process to ensure that it is authorised and correct
+for that machine.
+
+Verified boot extends from the moment of system reset to as far as you wish
+into the boot process. An example might be loading U-Boot from read-only
+memory, then loading a signed kernel, then using the kernel's dm-verity
+driver to mount a signed root filesystem.
+
+A key point is that it is possible to field-upgrade the software on machines
+which use verified boot. Since the machine will only run software that has
+been correctly signed, it is safe to read software from an updatable medium.
+It is also possible to add a secondary signed firmware image, in read-write
+memory, so that firmware can easily be upgraded in a secure manner.
+
+
+Signing
+-------
+Verified boot uses cryptographic algorithms to 'sign' software images.
+Images are signed using a private key known only to the signer, but can
+be verified using a public key. As its name suggests the public key can be
+made available without risk to the verification process. The private and
+public keys are mathematically related. For more information on how this
+works look up "public key cryptography" and "RSA" (a particular algorithm).
+
+The signing and verification process looks something like this:
+
+
+ Signing Verification
+ ======= ============
+
+ +--------------+ *
+ | RSA key pair | * +---------------+
+ | .key .crt | * | Public key in |
+ +--------------+ +------> public key ----->| trusted place |
+ | | * +---------------+
+ | | * |
+ v | * v
+ +---------+ | * +--------------+
+ | |----------+ * | |
+ | signer | * | U-Boot |
+ | |----------+ * | signature |--> yes/no
+ +---------+ | * | verification |
+ ^ | * | |
+ | | * +--------------+
+ | | * ^
+ +----------+ | * |
+ | Software | +----> signed image -------------+
+ | image | *
+ +----------+ *
+
+
+The signature algorithm relies only on the public key to do its work. Using
+this key it checks the signature that it finds in the image. If it verifies
+then we know that the image is OK.
+
+The public key from the signer allows us to verify and therefore trust
+software from updatable memory.
+
+It is critical that the public key be secure and cannot be tampered with.
+It can be stored in read-only memory, or perhaps protected by other on-chip
+crypto provided by some modern SOCs. If the public key can ben changed, then
+the verification is worthless.
+
+
+Chaining Images
+---------------
+The above method works for a signer providing images to a run-time U-Boot.
+It is also possible to extend this scheme to a second level, like this:
+
+1. Master private key is used by the signer to sign a first-stage image.
+2. Master public key is placed in read-only memory.
+2. Secondary private key is created and used to sign second-stage images.
+3. Secondary public key is placed in first stage images
+4. We use the master public key to verify the first-stage image. We then
+use the secondary public key in the first-stage image to verify the second-
+state image.
+5. This chaining process can go on indefinitely. It is recommended to use a
+different key at each stage, so that a compromise in one place will not
+affect the whole change.
+
+
+Flattened Image Tree (FIT)
+--------------------------
+The FIT format is alreay widely used in U-Boot. It is a flattened device
+tree (FDT) in a particular format, with images contained within. FITs
+include hashes to verify images, so it is relatively straightforward to
+add signatures as well.
+
+The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in
+a standard place. Then when a FIT it loaded it can be verified using that
+public key. Multiple keys and multiple signatures are supported.
+
+See signature.txt for more information.
+
+
+Simon Glass
+sjg@chromium.org
+1-1-13