Revert "Start the deprecation process for generic board"

We've run into a non-trivial conversion to CONFIG_SYS_GENERIC_BOARD so
we'll postpone this notice until right after v2014.04 is out.

This reverts commit 36c4b1d98059244c34ec3327d9cc9f3c552fd01b.

Signed-off-by: Tom Rini <trini@ti.com>

2 files changed, 0 insertions, 195 deletions

diff --git a/common/main.c b/common/main.c
index e54f63b956..8b6f274fa2 100644
--- a/common/main.c
+++ b/common/main.c
@@ -427,12 +427,6 @@ void main_loop(void)
 
 	bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, "main_loop");
 
-#ifndef CONFIG_SYS_GENERIC_BOARD
-	puts("Warning: Your board does not use generic board. Please read\n");
-	puts("doc/README.generic-board and take action. Boards not\n");
-	puts("upgraded by the late 2014 may break or be removed.\n");
-#endif
-
 #ifdef CONFIG_MODEM_SUPPORT
 	debug("DEBUG: main_loop:   do_mdm_init=%d\n", do_mdm_init);
 	if (do_mdm_init) {
diff --git a/doc/README.generic-board b/doc/README.generic-board
deleted file mode 100644
index 50d3a26849..0000000000
--- a/doc/README.generic-board
+++ /dev/null
@@ -1,189 +0,0 @@
-#
-# (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
-----------
-
-U-Boot has tranditionally had a board.c file for each architecture. This has
-introduced quite a lot of duplication, with each architecture tending to do
-initialisation slightly differently. To address this, a new 'generic board
-init' feature was introduced a year ago in March 2013 (further motivation is
-provided in the cover letter below).
-
-
-What has changed?
------------------
-
-The main change is that the arch/<arch>/lib/board.c file is being removed in
-favour of common/board_f.c (for pre-relocation init) and common/board_r.c
-(for post-relocation init).
-
-Related to this, the global_data and bd_t structures now have a core set of
-fields which are common to all architectures. Architecture-specific fields
-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
-------------------
-
-The full text of the original generic board series is reproduced below.
-
---8<-------------
-
-This series creates a generic board.c implementation which contains
-the essential functions of the major arch/xxx/lib/board.c files.
-
-What is the motivation for this change?
-
-1. There is a lot of repeated code in the board.c files. Any change to
-things like setting up the baud rate requires a change in 10 separate
-places.
-
-2. Since there are 10 separate files, adding a new feature which requires
-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
-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
-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
-achievable. There is no requirement that all code be common, only that
-the code that is common should be located in common/board.c rather than
-arch/xxx/lib/board.c.
-
-All the functions of board_init_f() and board_init_r() are broken into
-separate function calls so that they can easily be included or excluded
-for a particular architecture. It also makes it easier to adopt Graeme's
-initcall proposal when it is ready.
-
-http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
-
-This series removes the dependency on generic relocation. So relocation
-happens as one big chunk and is still completely arch-specific. See the
-relocation series for a proposed solution to this for ARM:
-
-http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
-
-or Graeme's recent x86 series v2:
-
-http://lists.denx.de/pipermail/u-boot/2012-January/114467.html
-
-Instead of moving over a whole architecture, this series takes the approach
-of simply enabling generic board support for an architecture. It is then up
-to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
-config file. If this is not done, then the code will be generated as
-before. This allows both sets of code to co-exist until we are comfortable
-with the generic approach, and enough boards run.
-
-ARM is a relatively large board.c file and one which I can test, therefore
-I think it is a good target for this series. On the other hand, x86 is
-relatively small and simple, but different enough that it introduces a
-few issues to be solved. So I have chosen both ARM and x86 for this series.
-After a suggestion from Wolfgang I have added PPC also. This is the
-largest and most feature-full board, so hopefully we have all bases
-covered in this RFC.
-
-A generic global_data structure is also required. This might upset a few
-people. Here is my basic reasoning: most fields are the same, all
-architectures include and need it, most global_data.h files already have
-#ifdefs to select fields for a particular SOC, so it is hard to
-see why architecures are different in this area. We can perhaps add a
-way to put architecture-specific fields into a separate header file, but
-for now I have judged that to be counter-productive.
-
-Similarly we need a generic bd_info structure, since generic code will
-be accessing it. I have done this in the same way as global_data and the
-same comments apply.
-
-There was dicussion on the list about passing gd_t around as a parameter
-to pre-relocation init functions. I think this makes sense, but it can
-be done as a separate change, and this series does not require it.
-
-While this series needs to stand on its own (as with the link script
-cleanup series and the generic relocation series) the goal is the
-unification of the board init code. So I hope we can address issues with
-this in mind, rather than focusing too narrowly on particular ARM, x86 or
-PPC issues.
-
-I have run-tested ARM on Tegra Seaboard only. To try it out, define
-CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on
-x86 and PPC at least it will hang, but if you are lucky it will print
-something first :-)
-
-I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all
-ARM, PPC and x86 boards. There are a few failures due to errors in
-the board config, which I have sent patches for. The main issue is
-just the difference between __bss_end and __bss_end__.
-
-Note: the first group of commits are required for this series to build,
-but could be separated out if required. I have included them here for
-convenience.
-
-------------->8--
-
-Simon Glass, sjg@chromium.org
-March 2014