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 36c4b1d980
.
Signed-off-by: Tom Rini <trini@ti.com>
master
parent
aafd2c5ddb
commit
04d2f0a9f3
@ -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 |
Loading…
Reference in new issue