dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller
[oweals/u-boot.git] / doc / README.generic-board
index 17da0b9f8776d837dd9ec8fea1ee4c686b1f8f01..32ddb1d19a274b3960b782b8700ff74807eb0657 100644 (file)
@@ -1,33 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0+
 #
 # (C) Copyright 2014 Google, Inc
 # Simon Glass <sjg@chromium.org>
 #
 # (C) Copyright 2014 Google, Inc
 # Simon Glass <sjg@chromium.org>
-#
-# SPDX-License-Identifier:     GPL-2.0+
-#
-
-DEPRECATION NOTICE FOR arch/<arch>/lib/board.c
-
-For board maintainers: Please submit patches for boards you maintain before
-July 2014, to make them use generic board.
-
-For architecture maintainers: Please submit patches to remove your
-architecture-specific board.c file before October 2014.
-
 
 Background
 ----------
 
 
 Background
 ----------
 
-U-Boot has traditionally had a board.c file for each architecture. This has
-introduced quite a lot of duplication, with each architecture tending to do
+U-Boot traditionally had a board.c file for each architecture. This introduced
+quite a lot of duplication, with each architecture tending to do
 initialisation slightly differently. To address this, a new 'generic board
 initialisation slightly differently. To address this, a new 'generic board
-init' feature was introduced a year ago in March 2013 (further motivation is
+init' feature was introduced in March 2013 (further motivation is
 provided in the cover letter below).
 
 provided in the cover letter below).
 
+All boards and architectures have moved to this as of mid 2016.
+
 
 What has changed?
 -----------------
 
 
 What has changed?
 -----------------
 
-The main change is that the arch/<arch>/lib/board.c file is being removed in
+The main change is that the arch/<arch>/lib/board.c file is removed in
 favour of common/board_f.c (for pre-relocation init) and common/board_r.c
 (for post-relocation init).
 
 favour of common/board_f.c (for pre-relocation init) and common/board_r.c
 (for post-relocation init).
 
@@ -36,52 +27,6 @@ fields which are common to all architectures. Architecture-specific fields
 have been moved to separate structures.
 
 
 have been moved to separate structures.
 
 
-Supported Arcthitectures
-------------------------
-
-If you are unlucky then your architecture may not support generic board.
-The following architectures are supported at the time of writing:
-
-   arc
-   arm
-   powerpc
-   sandbox
-   x86
-
-If your architecture is not supported, you need to adjust your
-arch/<arch>/config.mk file to include:
-
-   __HAVE_ARCH_GENERIC_BOARD := y
-
-and test it with a suitable board, as follows.
-
-
-Adding Support for your Board
------------------------------
-
-To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in
-your board config header file.
-
-Test that U-Boot still functions correctly on your board, and fix any
-problems you find. Don't be surprised if there are no problems - generic
-board has had a reasonable amount of testing with common boards.
-
-
-DeadLine
---------
-
-Please don't take this the wrong way - there is no intent to make your life
-miserable, and we have the greatest respect and admiration for U-Boot users.
-However, with any migration there has to be a period where the old way is
-deprecated and removed. Every patch to the deprecated code introduces a
-potential breakage in the new unused code. Therefore:
-
-Boards or architectures not converted over to general board by the
-end of 2014 may be forcibly changed over (potentially causing run-time
-breakage) or removed.
-
-
-
 Further Background
 ------------------
 
 Further Background
 ------------------
 
@@ -102,12 +47,12 @@ places.
 initialisation is painful since it must be independently added in 10
 places.
 
 initialisation is painful since it must be independently added in 10
 places.
 
-3. As time goes by the architectures naturely diverge since there is limited
-pressure to compare features or even CONFIG options against simiilar things
+3. As time goes by the architectures naturally diverge since there is limited
+pressure to compare features or even CONFIG options against similar things
 in other board.c files.
 
 4. New architectures must implement all the features all over again, and
 in other board.c files.
 
 4. New architectures must implement all the features all over again, and
-sometimes in subtley different ways. This places an unfair burden on getting
+sometimes in subtle different ways. This places an unfair burden on getting
 a new architecture fully functional and running with U-Boot.
 
 5. While it is a bit of a tricky change, I believe it is worthwhile and
 a new architecture fully functional and running with U-Boot.
 
 5. While it is a bit of a tricky change, I believe it is worthwhile and
@@ -187,3 +132,4 @@ convenience.
 
 Simon Glass, sjg@chromium.org
 March 2014
 
 Simon Glass, sjg@chromium.org
 March 2014
+Updated after final removal, May 2016