[U-Boot] [PATCH] Start the deprecation process for generic board
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/main.c | 6 ++ doc/README.generic-board | 189 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 195 insertions(+) create mode 100644 doc/README.generic-board
diff --git a/common/main.c b/common/main.c index 8b6f274..e54f63b 100644 --- a/common/main.c +++ b/common/main.c @@ -427,6 +427,12 @@ 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 new file mode 100644 index 0000000..50d3a26 --- /dev/null +++ b/doc/README.generic-board @@ -0,0 +1,189 @@ +# +# (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
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Best regards, Marek Vasut
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
Regards, Simon
On Thursday, April 03, 2014 at 07:35:10 PM, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
I did fix my boards (m28evk, m53evk) and there were no issues. PXA will need to wait a bit after I'm done with higher-prio stuff.
What I find really unfortunate is that this went in during rc3 and made all boards spew warning.
Best regards, Marek Vasut
On Thu, Apr 03, 2014 at 11:35:10AM -0600, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
So, Marek and I were discussing this on IRC as well. Given about a year and nothing converted (except for new things) I opted for the noisier approach. It really is a simple switch and for the record, if distro people would be so kind as to switch it on and report back that nothing happens, that'd be really helpful too.
On Thursday, April 03, 2014 at 09:01:30 PM, Tom Rini wrote:
On Thu, Apr 03, 2014 at 11:35:10AM -0600, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
So, Marek and I were discussing this on IRC as well. Given about a year and nothing converted (except for new things) I opted for the noisier approach. It really is a simple switch and for the record, if distro people would be so kind as to switch it on and report back that nothing happens, that'd be really helpful too.
Like I said already, it is fine for me to do this after the release, but not in -rc3 .
Best regards, Marek Vasut
Hi Marek,
On Thursday, April 03, 2014 at 09:01:30 PM, Tom Rini wrote:
On Thu, Apr 03, 2014 at 11:35:10AM -0600, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
So, Marek and I were discussing this on IRC as well. Given about a year and nothing converted (except for new things) I opted for the noisier approach. It really is a simple switch
Unfortunately, it isn't a simple switch in my case.
The +#define CONFIG_SYS_GENERIC_BOARD on the trats2 (and probably also trats) board causes problem with power management initialization. I will not be able to fix this and validate before v2014.04.
This issue will be fixed after the release.
and for the record, if distro people would be so kind as to switch it on and report back that nothing happens, that'd be really helpful too.
Like I said already, it is fine for me to do this after the release, but not in -rc3 .
+1
Best regards, Marek Vasut
Hi Lukasz,
On 4 April 2014 04:09, Lukasz Majewski l.majewski@samsung.com wrote:
Hi Marek,
On Thursday, April 03, 2014 at 09:01:30 PM, Tom Rini wrote:
On Thu, Apr 03, 2014 at 11:35:10AM -0600, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote:
On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass wrote: > We should move forward to remove the old board init code. > Add a prominent message to encourage maintainers to get > started on this work. > > Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
So, Marek and I were discussing this on IRC as well. Given about a year and nothing converted (except for new things) I opted for the noisier approach. It really is a simple switch
Unfortunately, it isn't a simple switch in my case.
The +#define CONFIG_SYS_GENERIC_BOARD on the trats2 (and probably also trats) board causes problem with power management initialization. I will not be able to fix this and validate before v2014.04.
This issue will be fixed after the release.
FWIW this works OK on exynos5 which has used generic board for a while. I'm not sure what the problem is - I don't see a change in the ordering of the call to power_init().
Regards, Simon
Hi Simon,
Hi Lukasz,
On 4 April 2014 04:09, Lukasz Majewski l.majewski@samsung.com wrote:
Hi Marek,
On Thursday, April 03, 2014 at 09:01:30 PM, Tom Rini wrote:
On Thu, Apr 03, 2014 at 11:35:10AM -0600, Simon Glass wrote:
Hi Marek,
On 3 April 2014 11:03, Marek Vasut marex@denx.de wrote:
On Friday, March 28, 2014 at 10:16:42 PM, Tom Rini wrote: > On Sat, Mar 22, 2014 at 05:14:51PM -0600, Simon Glass > wrote: > > We should move forward to remove the old board init > > code. Add a prominent message to encourage maintainers > > to get started on this work. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > Applied to u-boot/master, thanks!
It's now -rc3 , MW is long closed and my board start generating a warning. Even worse, all boards now generate this warning and I'm worried that this will cause the more attentive maintainers to take action and produce fast fixes which won't receive sufficient testing until release is out.
I seriously disagree with applying the patch for current release.
Despite the fact that it has been ~1 year and not a lot of people have taken action, I didn't actually expect it to go in right away, and I'm fine with a revert for this release if that's what Tom decides. But let's get it moving ASAP.
Also let me know if there are any questions about how to test. I wrote up a README in the patch, but am happy to expand it as things come up.
So, Marek and I were discussing this on IRC as well. Given about a year and nothing converted (except for new things) I opted for the noisier approach. It really is a simple switch
Unfortunately, it isn't a simple switch in my case.
The +#define CONFIG_SYS_GENERIC_BOARD on the trats2 (and probably also trats) board causes problem with power management initialization. I will not be able to fix this and validate before v2014.04.
This issue will be fixed after the release.
FWIW this works OK on exynos5 which has used generic board for a while. I'm not sure what the problem is - I don't see a change in the ordering of the call to power_init().
I've observed strange behaviour when battery was removed. I need time to investigate it.
Frankly, I plan to look closer on the power system after the release of v2014.04.
Regards, Simon
On 03/22/2014 04:14 PM, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Simon,
How much test has been done on powerpc boards? I randomly pick one MPC8536DS and it doesn't work. I have spent hours to track the difference and I am still struggling. I understand the first one could be more work, but if you have done any, especially 85xx family, please let me know.
York
Hi York,
On 25 April 2014 16:29, York Sun yorksun@freescale.com wrote:
On 03/22/2014 04:14 PM, Simon Glass wrote:
We should move forward to remove the old board init code. Add a prominent message to encourage maintainers to get started on this work.
Signed-off-by: Simon Glass sjg@chromium.org
Simon,
How much test has been done on powerpc boards? I randomly pick one MPC8536DS and it doesn't work. I have spent hours to track the difference and I am still struggling. I understand the first one could be more work, but if you have done any, especially 85xx family, please let me know.
I don't have any of those boards. I believe Wolfgang tested three of them some time ago.
See my other message - board_init_f() doesn't zero the global_data structure. It needs to be zeroed so make sure it is done elsewhere. Originally the code uses the cache which may have been zeroed, but now global_data is on the stack (still cache but maybe a different part?). Sorry I don't understand PowerPC very well, so I'm not sure of the pre-conditions.
Also, can you please be more specific about the failure?
Regards, Simon
participants (5)
-
Lukasz Majewski -
Marek Vasut -
Simon Glass -
Tom Rini -
York Sun