]>
Commit | Line | Data |
---|---|---|
0f605c15 SG |
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 |