Merge branch 'master' of git://git.denx.de/u-boot-arm

12 files changed, 395 insertions, 202 deletions

diff --git a/doc/DocBook/.gitignore b/doc/DocBook/.gitignore
index 90c1b112a15..720f245ceb1 100644
--- a/doc/DocBook/.gitignore
+++ b/doc/DocBook/.gitignore
@@ -1,4 +1,3 @@
-*/
 *.xml
 *.ps
 *.pdf
diff --git a/doc/DocBook/Makefile b/doc/DocBook/Makefile
index 29b79d7cd11..9b4a9b6762f 100644
--- a/doc/DocBook/Makefile
+++ b/doc/DocBook/Makefile
@@ -1,14 +1,12 @@
 ###
 # 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
+# See Documentation/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
+DOCBOOKS := linker_lists.xml stdio.xml
 
 ###
 # The build process is as follows (targets):
@@ -26,9 +24,9 @@ PS_METHOD	= $(prefer-db2x)
 
 ###
 # The targets that may be used.
-PHONY += $(obj).depend xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
+PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
 
-BOOKS := $(addprefix $(OBJTREE)/doc/DocBook/,$(DOCBOOKS))
+BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
 xmldocs: $(BOOKS)
 sgmldocs: xmldocs
 
@@ -53,10 +51,10 @@ installmandocs: mandocs
 
 ###
 #External programs used
-KERNELDOC = $(SRCTREE)/tools/kernel-doc/kernel-doc
-DOCPROC   = $(OBJTREE)/tools/kernel-doc/docproc
+KERNELDOC = $(srctree)/scripts/kernel-doc
+DOCPROC   = $(objtree)/scripts/docproc
 
-XMLTOFLAGS = -m $(SRCTREE)/doc/DocBook/stylesheet.xsl
+XMLTOFLAGS = -m $(srctree)/doc/DocBook/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
 
 ###
@@ -66,28 +64,36 @@ XMLTOFLAGS += --skip-validation
 #     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
+quiet_cmd_docproc = DOCPROC $@
+      cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+define rule_docproc
+	set -e;								\
+        $(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';) 	\
+        $(cmd_$(1)); 							\
+        ( 								\
+          echo 'cmd_$@ := $(cmd_$(1))'; 				\
+          echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`; 		\
+        ) > $(dir $@).$(notdir $@).cmd
+endef
+
+%.xml: %.tmpl FORCE
+	$(call if_changed_rule,docproc)
+
+###
+#Read in all saved dependency files
+cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
+
+ifneq ($(cmd_files),)
+  include $(cmd_files)
 endif
 
 ###
 # Changes in kernel-doc force a rebuild of all documentation
 $(BOOKS): $(KERNELDOC)
 
+# Tell kbuild to always build the programs
+always := $(hostprogs-y)
+
 notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
 		   exit 1
 db2xtemplate = db2TYPE -o $(dir $@) $<
@@ -113,37 +119,34 @@ endif
 quiet_cmd_db2ps = PS      $@
       cmd_db2ps = $(subst TYPE,ps, $($(PS_METHOD)template))
 %.ps : %.xml
-	$(call cmd_db2ps)
+	$(call cmd,db2ps)
 
 quiet_cmd_db2pdf = PDF     $@
       cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
 %.pdf : %.xml
-	$(call cmd_db2pdf)
+	$(call cmd,db2pdf)
 
 
 index = index.html
-main_idx = $(index)
+main_idx = doc/DocBook/$(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) && \
+		   echo '<h2>U-Boot Version: $(UBOOTVERSION)</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,%,$@) $< && \
+      cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
-	$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+        $(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)
+	$(call cmd,db2html)
 	@if [ ! -z "$(PNG-$(basename $(notdir $@)))" ]; then \
-	    cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
+            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
@@ -151,8 +154,8 @@ quiet_cmd_db2man = MAN     $@
 	@(which xmlto > /dev/null 2>&1) || \
 	 (echo "*** You need to install xmlto ***"; \
 	  exit 1)
-	$(Q)mkdir -p $(obj)man
-	$(call cmd_db2man)
+	$(Q)mkdir -p $(obj)/man
+	$(call cmd,db2man)
 	@touch $@
 
 ###
@@ -164,7 +167,7 @@ quiet_cmd_fig2eps = FIG2EPS $@
 	@(which fig2dev > /dev/null 2>&1) || \
 	 (echo "*** You need to install transfig ***"; \
 	  exit 1)
-	$(call cmd_fig2eps)
+	$(call cmd,fig2eps)
 
 quiet_cmd_fig2png = FIG2PNG $@
       cmd_fig2png = fig2dev -Lpng $< $@
@@ -173,7 +176,7 @@ quiet_cmd_fig2png = FIG2PNG $@
 	@(which fig2dev > /dev/null 2>&1) || \
 	 (echo "*** You need to install transfig ***"; \
 	  exit 1)
-	$(call cmd_fig2png)
+	$(call cmd,fig2png)
 
 ###
 # Rule to convert a .c file to inline XML documentation
@@ -219,9 +222,8 @@ clean-files := $(DOCBOOKS) \
 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))
+	$(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.
diff --git a/doc/DocBook/stylesheet.xsl b/doc/DocBook/stylesheet.xsl
index 8adce568b60..85b25275196 100644
--- a/doc/DocBook/stylesheet.xsl
+++ b/doc/DocBook/stylesheet.xsl
@@ -7,5 +7,4 @@
 <!-- <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/doc/README.ARC b/doc/README.ARC
new file mode 100644
index 00000000000..5f414fb2fa1
--- /dev/null
+++ b/doc/README.ARC
@@ -0,0 +1,27 @@
+Synopsys' DesignWare(r) ARC(r) Processors are a family of 32-bit CPUs
+that SoC designers can optimize for a wide range of uses, from deeply embedded
+to high-performance host applications.
+
+More information on ARC cores avaialble here:
+http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx
+
+Designers can differentiate their products by using patented configuration
+technology to tailor each ARC processor instance to meet specific performance,
+power and area requirements.
+
+The DesignWare ARC processors are also extendable, allowing designers to add
+their own custom instructions that dramatically increase performance.
+
+Synopsys' ARC processors have been used by over 170 customers worldwide who
+collectively ship more than 1 billion ARC-based chips annually.
+
+All DesignWare ARC processors utilize a 16-/32-bit ISA that provides excellent
+performance and code density for embedded and host SoC applications.
+
+The RISC microprocessors are synthesizable and can be implemented in any foundry
+or process, and are supported by a complete suite of development tools.
+
+The ARC GNU toolchain with support for all ARC Processors can be downloaded
+from here (available pre-built toolchains as well):
+
+https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases
diff --git a/doc/README.arm-unaligned-accesses b/doc/README.arm-unaligned-accesses
deleted file mode 100644
index c37d1358522..00000000000
--- a/doc/README.arm-unaligned-accesses
+++ /dev/null
@@ -1,122 +0,0 @@
-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/doc/README.b4860qds b/doc/README.b4860qds
index f8a79dbb25c..3da77d9f0f8 100644
--- a/doc/README.b4860qds
+++ b/doc/README.b4860qds
@@ -230,14 +230,14 @@ NOR Flash memory Map on B4860 and B4420QDS
 0xEFF40000	0xEFFFFFFF	u-boot (current bank)		768KB
 0xEFF20000	0xEFF3FFFF	u-boot env (current bank)	128KB
 0xEFF00000	0xEFF1FFFF	FMAN Ucode (current bank)	128KB
-0xEF300000	0xEFF3FFFF	rootfs (alternate bank)		12MB + 256KB
+0xEF300000	0xEFEFFFFF	rootfs (alternate bank)		12MB
 0xEE800000	0xEE8FFFFF	device tree (alternate bank)	1MB
 0xEE020000	0xEE6FFFFF	Linux.uImage (alternate bank)	6MB+896KB
 0xEE000000	0xEE01FFFF	RCW (alternate bank)		128KB
 0xEDF40000	0xEDFFFFFF	u-boot (alternate bank)		768KB
 0xEDF20000	0xEDF3FFFF	u-boot env (alternate bank)	128KB
 0xEDF00000	0xEDF1FFFF	FMAN ucode (alternate bank)	128KB
-0xED300000	0xEDF3FFFF	rootfs (current bank)		12MB+256MB
+0xED300000	0xEDEFFFFF	rootfs (current bank)		12MB
 0xEC800000	0xEC8FFFFF	device tree (current bank)	1MB
 0xEC020000	0xEC6FFFFF	Linux.uImage (current bank)	6MB+896KB
 0xEC000000	0xEC01FFFF	RCW (current bank)		128KB
diff --git a/doc/README.designware_eth b/doc/README.designware_eth
deleted file mode 100644
index 25ec6bd9699..00000000000
--- a/doc/README.designware_eth
+++ /dev/null
@@ -1,25 +0,0 @@
-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/doc/README.scrapyard b/doc/README.scrapyard
index 2aed8559939..6b41445faa0 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -11,6 +11,11 @@ easily if here is something they might want to dig for...
 
 Board            Arch        CPU            Commit      Removed     Last known maintainer/contact
 =================================================================================================
+dvl_host         arm         ixp            -           2014-01-28  Michael Schwingen <[email protected]>
+actux4           arm         ixp            -           2014-01-28  Michael Schwingen <[email protected]>
+actux3           arm         ixp            -           2014-01-28  Michael Schwingen <[email protected]>
+actux2           arm         ixp            -           2014-01-28  Michael Schwingen <[email protected]>
+actux1           arm         ixp            -           2014-01-28  Michael Schwingen <[email protected]>
 mx1ads           arm         arm920t        -           2014-01-13
 mini2440         arm         arm920t        -           2014-01-13  Gabriel Huau <[email protected]>
 omap730p2        arm         arm926ejs      79c5c08d    2013-11-11
diff --git a/doc/README.unaligned-memory-access.txt b/doc/README.unaligned-memory-access.txt
new file mode 100644
index 00000000000..00529f5dac7
--- /dev/null
+++ b/doc/README.unaligned-memory-access.txt
@@ -0,0 +1,240 @@
+Editors note: This document is _heavily_ cribbed from the Linux Kernel, with
+really only the section about "Alignment vs. Networking" removed.
+
+UNALIGNED MEMORY ACCESSES
+=========================
+
+Linux runs on a wide variety of architectures which have varying behaviour
+when it comes to memory access. This document presents some details about
+unaligned accesses, why you need to write code that doesn't cause them,
+and how to write such code!
+
+
+The definition of an unaligned access
+=====================================
+
+Unaligned memory accesses occur when you try to read N bytes of data starting
+from an address that is not evenly divisible by N (i.e. addr % N != 0).
+For example, reading 4 bytes of data from address 0x10004 is fine, but
+reading 4 bytes of data from address 0x10005 would be an unaligned memory
+access.
+
+The above may seem a little vague, as memory access can happen in different
+ways. The context here is at the machine code level: certain instructions read
+or write a number of bytes to or from memory (e.g. movb, movw, movl in x86
+assembly). As will become clear, it is relatively easy to spot C statements
+which will compile to multiple-byte memory access instructions, namely when
+dealing with types such as u16, u32 and u64.
+
+
+Natural alignment
+=================
+
+The rule mentioned above forms what we refer to as natural alignment:
+When accessing N bytes of memory, the base memory address must be evenly
+divisible by N, i.e. addr % N == 0.
+
+When writing code, assume the target architecture has natural alignment
+requirements.
+
+In reality, only a few architectures require natural alignment on all sizes
+of memory access. However, we must consider ALL supported architectures;
+writing code that satisfies natural alignment requirements is the easiest way
+to achieve full portability.
+
+
+Why unaligned access is bad
+===========================
+
+The effects of performing an unaligned memory access vary from architecture
+to architecture. It would be easy to write a whole document on the differences
+here; a summary of the common scenarios is presented below:
+
+ - Some architectures are able to perform unaligned memory accesses
+   transparently, but there is usually a significant performance cost.
+ - Some architectures raise processor exceptions when unaligned accesses
+   happen. The exception handler is able to correct the unaligned access,
+   at significant cost to performance.
+ - Some architectures raise processor exceptions when unaligned accesses
+   happen, but the exceptions do not contain enough information for the
+   unaligned access to be corrected.
+ - Some architectures are not capable of unaligned memory access, but will
+   silently perform a different memory access to the one that was requested,
+   resulting in a subtle code bug that is hard to detect!
+
+It should be obvious from the above that if your code causes unaligned
+memory accesses to happen, your code will not work correctly on certain
+platforms and will cause performance problems on others.
+
+
+Code that does not cause unaligned access
+=========================================
+
+At first, the concepts above may seem a little hard to relate to actual
+coding practice. After all, you don't have a great deal of control over
+memory addresses of certain variables, etc.
+
+Fortunately things are not too complex, as in most cases, the compiler
+ensures that things will work for you. For example, take the following
+structure:
+
+	struct foo {
+		u16 field1;
+		u32 field2;
+		u8 field3;
+	};
+
+Let us assume that an instance of the above structure resides in memory
+starting at address 0x10000. With a basic level of understanding, it would
+not be unreasonable to expect that accessing field2 would cause an unaligned
+access. You'd be expecting field2 to be located at offset 2 bytes into the
+structure, i.e. address 0x10002, but that address is not evenly divisible
+by 4 (remember, we're reading a 4 byte value here).
+
+Fortunately, the compiler understands the alignment constraints, so in the
+above case it would insert 2 bytes of padding in between field1 and field2.
+Therefore, for standard structure types you can always rely on the compiler
+to pad structures so that accesses to fields are suitably aligned (assuming
+you do not cast the field to a type of different length).
+
+Similarly, you can also rely on the compiler to align variables and function
+parameters to a naturally aligned scheme, based on the size of the type of
+the variable.
+
+At this point, it should be clear that accessing a single byte (u8 or char)
+will never cause an unaligned access, because all memory addresses are evenly
+divisible by one.
+
+On a related topic, with the above considerations in mind you may observe
+that you could reorder the fields in the structure in order to place fields
+where padding would otherwise be inserted, and hence reduce the overall
+resident memory size of structure instances. The optimal layout of the
+above example is:
+
+	struct foo {
+		u32 field2;
+		u16 field1;
+		u8 field3;
+	};
+
+For a natural alignment scheme, the compiler would only have to add a single
+byte of padding at the end of the structure. This padding is added in order
+to satisfy alignment constraints for arrays of these structures.
+
+Another point worth mentioning is the use of __attribute__((packed)) on a
+structure type. This GCC-specific attribute tells the compiler never to
+insert any padding within structures, useful when you want to use a C struct
+to represent some data that comes in a fixed arrangement 'off the wire'.
+
+You might be inclined to believe that usage of this attribute can easily
+lead to unaligned accesses when accessing fields that do not satisfy
+architectural alignment requirements. However, again, the compiler is aware
+of the alignment constraints and will generate extra instructions to perform
+the memory access in a way that does not cause unaligned access. Of course,
+the extra instructions obviously cause a loss in performance compared to the
+non-packed case, so the packed attribute should only be used when avoiding
+structure padding is of importance.
+
+
+Code that causes unaligned access
+=================================
+
+With the above in mind, let's move onto a real life example of a function
+that can cause an unaligned memory access. The following function taken
+from the Linux Kernel's include/linux/etherdevice.h is an optimized routine
+to compare two ethernet MAC addresses for equality.
+
+bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
+{
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+	u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
+		   ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
+
+	return fold == 0;
+#else
+	const u16 *a = (const u16 *)addr1;
+	const u16 *b = (const u16 *)addr2;
+	return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
+#endif
+}
+
+In the above function, when the hardware has efficient unaligned access
+capability, there is no issue with this code.  But when the hardware isn't
+able to access memory on arbitrary boundaries, the reference to a[0] causes
+2 bytes (16 bits) to be read from memory starting at address addr1.
+
+Think about what would happen if addr1 was an odd address such as 0x10003.
+(Hint: it'd be an unaligned access.)
+
+Despite the potential unaligned access problems with the above function, it
+is included in the kernel anyway but is understood to only work normally on
+16-bit-aligned addresses. It is up to the caller to ensure this alignment or
+not use this function at all. This alignment-unsafe function is still useful
+as it is a decent optimization for the cases when you can ensure alignment,
+which is true almost all of the time in ethernet networking context.
+
+
+Here is another example of some code that could cause unaligned accesses:
+	void myfunc(u8 *data, u32 value)
+	{
+		[...]
+		*((u32 *) data) = cpu_to_le32(value);
+		[...]
+	}
+
+This code will cause unaligned accesses every time the data parameter points
+to an address that is not evenly divisible by 4.
+
+In summary, the 2 main scenarios where you may run into unaligned access
+problems involve:
+ 1. Casting variables to types of different lengths
+ 2. Pointer arithmetic followed by access to at least 2 bytes of data
+
+
+Avoiding unaligned accesses
+===========================
+
+The easiest way to avoid unaligned access is to use the get_unaligned() and
+put_unaligned() macros provided by the <asm/unaligned.h> header file.
+
+Going back to an earlier example of code that potentially causes unaligned
+access:
+
+	void myfunc(u8 *data, u32 value)
+	{
+		[...]
+		*((u32 *) data) = cpu_to_le32(value);
+		[...]
+	}
+
+To avoid the unaligned memory access, you would rewrite it as follows:
+
+	void myfunc(u8 *data, u32 value)
+	{
+		[...]
+		value = cpu_to_le32(value);
+		put_unaligned(value, (u32 *) data);
+		[...]
+	}
+
+The get_unaligned() macro works similarly. Assuming 'data' is a pointer to
+memory and you wish to avoid unaligned access, its usage is as follows:
+
+	u32 value = get_unaligned((u32 *) data);
+
+These macros work for memory accesses of any length (not just 32 bits as
+in the examples above). Be aware that when compared to standard access of
+aligned memory, using these macros to access unaligned memory can be costly in
+terms of performance.
+
+If use of such macros is not convenient, another option is to use memcpy(),
+where the source or destination (or both) are of type u8* or unsigned char*.
+Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+--
+In the Linux Kernel,
+Authors: Daniel Drake <[email protected]>,
+         Johannes Berg <[email protected]>
+With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
diff --git a/doc/SPI/README.ti_qspi_am43x_test b/doc/SPI/README.ti_qspi_am43x_test
new file mode 100644
index 00000000000..8fbf10b57a1
--- /dev/null
+++ b/doc/SPI/README.ti_qspi_am43x_test
@@ -0,0 +1,76 @@
+Testing details-
+----------------
+
+This doc simply illustrated the testing details of qspi flash
+driver with Macronix M25L51235 flash device.
+
+The test includes
+- probing the flash device
+- erasing the flash device
+- Writing to flash
+- Reading the contents of the flash.
+
+Test Log
+--------
+
+Hit any key to stop autoboot:  0
+U-Boot# sf probe 0
+SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
+U-Boot# sf erase 0 0x80000
+SF: 524288 bytes @ 0x0 Erased: OK
+U-Boot# mw 81000000 0xdededede 0x40000
+U-Boot# sf write 81000000 0 0x40000
+SF: 262144 bytes @ 0x0 Written: OK
+U-Boot# sf read 82000000 0 0x40000
+SF: 262144 bytes @ 0x0 Read: OK
+U-Boot# md 0x82000000
+82000000: dededede dededede dededede dededede    ................
+82000010: dededede dededede dededede dededede    ................
+82000020: dededede dededede dededede dededede    ................
+82000030: dededede dededede dededede dededede    ................
+82000040: dededede dededede dededede dededede    ................
+82000050: dededede dededede dededede dededede    ................
+82000060: dededede dededede dededede dededede    ................
+82000070: dededede dededede dededede dededede    ................
+82000080: dededede dededede dededede dededede    ................
+82000090: dededede dededede dededede dededede    ................
+820000a0: dededede dededede dededede dededede    ................
+820000b0: dededede dededede dededede dededede    ................
+820000c0: dededede dededede dededede dededede    ................
+820000d0: dededede dededede dededede dededede    ................
+820000e0: dededede dededede dededede dededede    ................
+820000f0: dededede dededede dededede dededede    ................
+U-Boot# md 0x82010000
+82010000: dededede dededede dededede dededede    ................
+82010010: dededede dededede dededede dededede    ................
+82010020: dededede dededede dededede dededede    ................
+82010030: dededede dededede dededede dededede    ................
+82010040: dededede dededede dededede dededede    ................
+82010050: dededede dededede dededede dededede    ................
+82010060: dededede dededede dededede dededede    ................
+82010070: dededede dededede dededede dededede    ................
+82010080: dededede dededede dededede dededede    ................
+82010090: dededede dededede dededede dededede    ................
+820100a0: dededede dededede dededede dededede    ................
+820100b0: dededede dededede dededede dededede    ................
+820100c0: dededede dededede dededede dededede    ................
+820100d0: dededede dededede dededede dededede    ................
+820100e0: dededede dededede dededede dededede    ................
+820100f0: dededede dededede dededede dededede    ................
+U-Boot# md 0x82030000
+82030000: dededede dededede dededede dededede    ................
+82030010: dededede dededede dededede dededede    ................
+82030020: dededede dededede dededede dededede    ................
+82030030: dededede dededede dededede dededede    ................
+82030040: dededede dededede dededede dededede    ................
+82030050: dededede dededede dededede dededede    ................
+82030060: dededede dededede dededede dededede    ................
+82030070: dededede dededede dededede dededede    ................
+82030080: dededede dededede dededede dededede    ................
+82030090: dededede dededede dededede dededede    ................
+820300a0: dededede dededede dededede dededede    ................
+820300b0: dededede dededede dededede dededede    ................
+820300c0: dededede dededede dededede dededede    ................
+820300d0: dededede dededede dededede dededede    ................
+820300e0: dededede dededede dededede dededede    ................
+820300f0: dededede dededede dededede dededede    ................
diff --git a/doc/driver-model/UDM-pci.txt b/doc/driver-model/UDM-pci.txt
index 059a4329fb9..1dce99de3dc 100644
--- a/doc/driver-model/UDM-pci.txt
+++ b/doc/driver-model/UDM-pci.txt
@@ -125,10 +125,6 @@ III) Analysis of in-tree drivers
       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.
diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
index 279e941fc03..ed804a8e7e5 100644
--- a/doc/driver-model/UDM-serial.txt
+++ b/doc/driver-model/UDM-serial.txt
@@ -101,10 +101,6 @@ III) Analysis of in-tree drivers
   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.