Commit 04d2f0a9f33112bd70ce4d9c451fdca1682e3a59
1 parent
aafd2c5ddb
Exists in
v2017.01-smarct4x
and in
48 other branches
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>
Showing 2 changed files with 0 additions and 195 deletions Side-by-side Diff
common/main.c
... | ... | @@ -427,12 +427,6 @@ |
427 | 427 | |
428 | 428 | bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, "main_loop"); |
429 | 429 | |
430 | -#ifndef CONFIG_SYS_GENERIC_BOARD | |
431 | - puts("Warning: Your board does not use generic board. Please read\n"); | |
432 | - puts("doc/README.generic-board and take action. Boards not\n"); | |
433 | - puts("upgraded by the late 2014 may break or be removed.\n"); | |
434 | -#endif | |
435 | - | |
436 | 430 | #ifdef CONFIG_MODEM_SUPPORT |
437 | 431 | debug("DEBUG: main_loop: do_mdm_init=%d\n", do_mdm_init); |
438 | 432 | if (do_mdm_init) { |
doc/README.generic-board
1 | -# | |
2 | -# (C) Copyright 2014 Google, Inc | |
3 | -# Simon Glass <sjg@chromium.org> | |
4 | -# | |
5 | -# SPDX-License-Identifier: GPL-2.0+ | |
6 | -# | |
7 | - | |
8 | -DEPRECATION NOTICE FOR arch/<arch>/lib/board.c | |
9 | - | |
10 | -For board maintainers: Please submit patches for boards you maintain before | |
11 | -July 2014, to make them use generic board. | |
12 | - | |
13 | -For architecture maintainers: Please submit patches to remove your | |
14 | -architecture-specific board.c file before October 2014. | |
15 | - | |
16 | - | |
17 | -Background | |
18 | ----------- | |
19 | - | |
20 | -U-Boot has tranditionally had a board.c file for each architecture. This has | |
21 | -introduced quite a lot of duplication, with each architecture tending to do | |
22 | -initialisation slightly differently. To address this, a new 'generic board | |
23 | -init' feature was introduced a year ago in March 2013 (further motivation is | |
24 | -provided in the cover letter below). | |
25 | - | |
26 | - | |
27 | -What has changed? | |
28 | ------------------ | |
29 | - | |
30 | -The main change is that the arch/<arch>/lib/board.c file is being removed in | |
31 | -favour of common/board_f.c (for pre-relocation init) and common/board_r.c | |
32 | -(for post-relocation init). | |
33 | - | |
34 | -Related to this, the global_data and bd_t structures now have a core set of | |
35 | -fields which are common to all architectures. Architecture-specific fields | |
36 | -have been moved to separate structures. | |
37 | - | |
38 | - | |
39 | -Supported Arcthitectures | |
40 | ------------------------- | |
41 | - | |
42 | -If you are unlucky then your architecture may not support generic board. | |
43 | -The following architectures are supported at the time of writing: | |
44 | - | |
45 | - arc | |
46 | - arm | |
47 | - powerpc | |
48 | - sandbox | |
49 | - x86 | |
50 | - | |
51 | -If your architecture is not supported, you need to adjust your | |
52 | -arch/<arch>/config.mk file to include: | |
53 | - | |
54 | - __HAVE_ARCH_GENERIC_BOARD := y | |
55 | - | |
56 | -and test it with a suitable board, as follows. | |
57 | - | |
58 | - | |
59 | -Adding Support for your Board | |
60 | ------------------------------ | |
61 | - | |
62 | -To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in | |
63 | -your board config header file. | |
64 | - | |
65 | -Test that U-Boot still functions correctly on your board, and fix any | |
66 | -problems you find. Don't be surprised if there are no problems - generic | |
67 | -board has had a reasonable amount of testing with common boards. | |
68 | - | |
69 | - | |
70 | -DeadLine | |
71 | --------- | |
72 | - | |
73 | -Please don't take this the wrong way - there is no intent to make your life | |
74 | -miserable, and we have the greatest respect and admiration for U-Boot users. | |
75 | -However, with any migration there has to be a period where the old way is | |
76 | -deprecated and removed. Every patch to the deprecated code introduces a | |
77 | -potential breakage in the new unused code. Therefore: | |
78 | - | |
79 | -Boards or architectures not converted over to general board by the | |
80 | -end of 2014 may be forcibly changed over (potentially causing run-time | |
81 | -breakage) or removed. | |
82 | - | |
83 | - | |
84 | - | |
85 | -Further Background | |
86 | ------------------- | |
87 | - | |
88 | -The full text of the original generic board series is reproduced below. | |
89 | - | |
90 | ---8<------------- | |
91 | - | |
92 | -This series creates a generic board.c implementation which contains | |
93 | -the essential functions of the major arch/xxx/lib/board.c files. | |
94 | - | |
95 | -What is the motivation for this change? | |
96 | - | |
97 | -1. There is a lot of repeated code in the board.c files. Any change to | |
98 | -things like setting up the baud rate requires a change in 10 separate | |
99 | -places. | |
100 | - | |
101 | -2. Since there are 10 separate files, adding a new feature which requires | |
102 | -initialisation is painful since it must be independently added in 10 | |
103 | -places. | |
104 | - | |
105 | -3. As time goes by the architectures naturely diverge since there is limited | |
106 | -pressure to compare features or even CONFIG options against simiilar things | |
107 | -in other board.c files. | |
108 | - | |
109 | -4. New architectures must implement all the features all over again, and | |
110 | -sometimes in subtley different ways. This places an unfair burden on getting | |
111 | -a new architecture fully functional and running with U-Boot. | |
112 | - | |
113 | -5. While it is a bit of a tricky change, I believe it is worthwhile and | |
114 | -achievable. There is no requirement that all code be common, only that | |
115 | -the code that is common should be located in common/board.c rather than | |
116 | -arch/xxx/lib/board.c. | |
117 | - | |
118 | -All the functions of board_init_f() and board_init_r() are broken into | |
119 | -separate function calls so that they can easily be included or excluded | |
120 | -for a particular architecture. It also makes it easier to adopt Graeme's | |
121 | -initcall proposal when it is ready. | |
122 | - | |
123 | -http://lists.denx.de/pipermail/u-boot/2012-January/114499.html | |
124 | - | |
125 | -This series removes the dependency on generic relocation. So relocation | |
126 | -happens as one big chunk and is still completely arch-specific. See the | |
127 | -relocation series for a proposed solution to this for ARM: | |
128 | - | |
129 | -http://lists.denx.de/pipermail/u-boot/2011-December/112928.html | |
130 | - | |
131 | -or Graeme's recent x86 series v2: | |
132 | - | |
133 | -http://lists.denx.de/pipermail/u-boot/2012-January/114467.html | |
134 | - | |
135 | -Instead of moving over a whole architecture, this series takes the approach | |
136 | -of simply enabling generic board support for an architecture. It is then up | |
137 | -to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board | |
138 | -config file. If this is not done, then the code will be generated as | |
139 | -before. This allows both sets of code to co-exist until we are comfortable | |
140 | -with the generic approach, and enough boards run. | |
141 | - | |
142 | -ARM is a relatively large board.c file and one which I can test, therefore | |
143 | -I think it is a good target for this series. On the other hand, x86 is | |
144 | -relatively small and simple, but different enough that it introduces a | |
145 | -few issues to be solved. So I have chosen both ARM and x86 for this series. | |
146 | -After a suggestion from Wolfgang I have added PPC also. This is the | |
147 | -largest and most feature-full board, so hopefully we have all bases | |
148 | -covered in this RFC. | |
149 | - | |
150 | -A generic global_data structure is also required. This might upset a few | |
151 | -people. Here is my basic reasoning: most fields are the same, all | |
152 | -architectures include and need it, most global_data.h files already have | |
153 | -#ifdefs to select fields for a particular SOC, so it is hard to | |
154 | -see why architecures are different in this area. We can perhaps add a | |
155 | -way to put architecture-specific fields into a separate header file, but | |
156 | -for now I have judged that to be counter-productive. | |
157 | - | |
158 | -Similarly we need a generic bd_info structure, since generic code will | |
159 | -be accessing it. I have done this in the same way as global_data and the | |
160 | -same comments apply. | |
161 | - | |
162 | -There was dicussion on the list about passing gd_t around as a parameter | |
163 | -to pre-relocation init functions. I think this makes sense, but it can | |
164 | -be done as a separate change, and this series does not require it. | |
165 | - | |
166 | -While this series needs to stand on its own (as with the link script | |
167 | -cleanup series and the generic relocation series) the goal is the | |
168 | -unification of the board init code. So I hope we can address issues with | |
169 | -this in mind, rather than focusing too narrowly on particular ARM, x86 or | |
170 | -PPC issues. | |
171 | - | |
172 | -I have run-tested ARM on Tegra Seaboard only. To try it out, define | |
173 | -CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on | |
174 | -x86 and PPC at least it will hang, but if you are lucky it will print | |
175 | -something first :-) | |
176 | - | |
177 | -I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all | |
178 | -ARM, PPC and x86 boards. There are a few failures due to errors in | |
179 | -the board config, which I have sent patches for. The main issue is | |
180 | -just the difference between __bss_end and __bss_end__. | |
181 | - | |
182 | -Note: the first group of commits are required for this series to build, | |
183 | -but could be separated out if required. I have included them here for | |
184 | -convenience. | |
185 | - | |
186 | -------------->8-- | |
187 | - | |
188 | -Simon Glass, sjg@chromium.org | |
189 | -March 2014 |