1# 2# (C) Copyright 2014 Google, Inc 3# Simon Glass <sjg@chromium.org> 4# 5# SPDX-License-Identifier: GPL-2.0+ 6# 7 8Background 9---------- 10 11U-Boot traditionally had a board.c file for each architecture. This introduced 12quite a lot of duplication, with each architecture tending to do 13initialisation slightly differently. To address this, a new 'generic board 14init' feature was introduced in March 2013 (further motivation is 15provided in the cover letter below). 16 17All boards and architectures have moved to this as of mid 2016. 18 19 20What has changed? 21----------------- 22 23The main change is that the arch/<arch>/lib/board.c file is removed in 24favour of common/board_f.c (for pre-relocation init) and common/board_r.c 25(for post-relocation init). 26 27Related to this, the global_data and bd_t structures now have a core set of 28fields which are common to all architectures. Architecture-specific fields 29have been moved to separate structures. 30 31 32Further Background 33------------------ 34 35The full text of the original generic board series is reproduced below. 36 37--8<------------- 38 39This series creates a generic board.c implementation which contains 40the essential functions of the major arch/xxx/lib/board.c files. 41 42What is the motivation for this change? 43 441. There is a lot of repeated code in the board.c files. Any change to 45things like setting up the baud rate requires a change in 10 separate 46places. 47 482. Since there are 10 separate files, adding a new feature which requires 49initialisation is painful since it must be independently added in 10 50places. 51 523. As time goes by the architectures naturally diverge since there is limited 53pressure to compare features or even CONFIG options against similar things 54in other board.c files. 55 564. New architectures must implement all the features all over again, and 57sometimes in subtle different ways. This places an unfair burden on getting 58a new architecture fully functional and running with U-Boot. 59 605. While it is a bit of a tricky change, I believe it is worthwhile and 61achievable. There is no requirement that all code be common, only that 62the code that is common should be located in common/board.c rather than 63arch/xxx/lib/board.c. 64 65All the functions of board_init_f() and board_init_r() are broken into 66separate function calls so that they can easily be included or excluded 67for a particular architecture. It also makes it easier to adopt Graeme's 68initcall proposal when it is ready. 69 70http://lists.denx.de/pipermail/u-boot/2012-January/114499.html 71 72This series removes the dependency on generic relocation. So relocation 73happens as one big chunk and is still completely arch-specific. See the 74relocation series for a proposed solution to this for ARM: 75 76http://lists.denx.de/pipermail/u-boot/2011-December/112928.html 77 78or Graeme's recent x86 series v2: 79 80http://lists.denx.de/pipermail/u-boot/2012-January/114467.html 81 82Instead of moving over a whole architecture, this series takes the approach 83of simply enabling generic board support for an architecture. It is then up 84to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board 85config file. If this is not done, then the code will be generated as 86before. This allows both sets of code to co-exist until we are comfortable 87with the generic approach, and enough boards run. 88 89ARM is a relatively large board.c file and one which I can test, therefore 90I think it is a good target for this series. On the other hand, x86 is 91relatively small and simple, but different enough that it introduces a 92few issues to be solved. So I have chosen both ARM and x86 for this series. 93After a suggestion from Wolfgang I have added PPC also. This is the 94largest and most feature-full board, so hopefully we have all bases 95covered in this RFC. 96 97A generic global_data structure is also required. This might upset a few 98people. Here is my basic reasoning: most fields are the same, all 99architectures include and need it, most global_data.h files already have 100#ifdefs to select fields for a particular SOC, so it is hard to 101see why architecures are different in this area. We can perhaps add a 102way to put architecture-specific fields into a separate header file, but 103for now I have judged that to be counter-productive. 104 105Similarly we need a generic bd_info structure, since generic code will 106be accessing it. I have done this in the same way as global_data and the 107same comments apply. 108 109There was dicussion on the list about passing gd_t around as a parameter 110to pre-relocation init functions. I think this makes sense, but it can 111be done as a separate change, and this series does not require it. 112 113While this series needs to stand on its own (as with the link script 114cleanup series and the generic relocation series) the goal is the 115unification of the board init code. So I hope we can address issues with 116this in mind, rather than focusing too narrowly on particular ARM, x86 or 117PPC issues. 118 119I have run-tested ARM on Tegra Seaboard only. To try it out, define 120CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on 121x86 and PPC at least it will hang, but if you are lucky it will print 122something first :-) 123 124I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all 125ARM, PPC and x86 boards. There are a few failures due to errors in 126the board config, which I have sent patches for. The main issue is 127just the difference between __bss_end and __bss_end__. 128 129Note: the first group of commits are required for this series to build, 130but could be separated out if required. I have included them here for 131convenience. 132 133------------->8-- 134 135Simon Glass, sjg@chromium.org 136March 2014 137Updated after final removal, May 2016 138