From 36c4b1d98059244c34ec3327d9cc9f3c552fd01b Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 22 Mar 2014 17:14:51 -0600 Subject: 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 --- doc/README.generic-board | 189 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 doc/README.generic-board (limited to 'doc') 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 +# +# SPDX-License-Identifier: GPL-2.0+ +# + +DEPRECATION NOTICE FOR 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//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//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 -- cgit v1.1 From 39206382dea929b6a834c212b431821e06e68f39 Mon Sep 17 00:00:00 2001 From: Przemyslaw Marczak Date: Wed, 2 Apr 2014 10:20:06 +0200 Subject: cmd:gpt: randomly generate each partition uuid if undefined Changes: - randomly generate partition uuid if any is undefined and CONFIG_RAND_UUID is defined - print debug info about set/unset/generated uuid - update doc/README.gpt Signed-off-by: Przemyslaw Marczak Acked-by: Lukasz Majewski Cc: Piotr Wilczek Cc: Tom Rini Cc: Stephen Warren Cc: Lukasz Majewski --- doc/README.gpt | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/README.gpt b/doc/README.gpt index 5c133f3..f822894 100644 --- a/doc/README.gpt +++ b/doc/README.gpt @@ -132,8 +132,8 @@ of the Primary. ---------------------- Offset Size Description - 0 16 B Partition type GUID - 16 16 B Unique partition GUID + 0 16 B Partition type GUID (Big Endian) + 16 16 B Unique partition GUID in (Big Endian) 32 8 B First LBA (Little Endian) 40 8 B Last LBA (inclusive) 48 8 B Attribute flags [+] @@ -160,6 +160,9 @@ To restore GUID partition table one needs to: Fields 'name', 'size' and 'uuid' are mandatory for every partition. The field 'start' is optional. + option: CONFIG_RANDOM_UUID + If any partition "UUID" no exists then it is randomly generated. + 2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT' 2. From u-boot prompt type: @@ -168,11 +171,20 @@ To restore GUID partition table one needs to: Useful info: ============ -Two programs, namely: 'fdisk' and 'parted' are recommended to work with GPT -recovery. Parted is able to handle GUID partitions. Unfortunately the 'fdisk' -hasn't got such ability. +Two programs, namely: 'gdisk' and 'parted' are recommended to work with GPT +recovery. Both are able to handle GUID partitions. Please, pay attention at -l switch for parted. "uuid" program is recommended to generate UUID string. Moreover it can decode (-d switch) passed in UUID string. It can be used to generate partitions UUID passed to u-boot environment variables. +If optional CONFIG_RANDOM_UUID is defined then for any partition which environment +uuid is unset, uuid is randomly generated and stored in correspond environment +variable. + +note: +Each string block of UUID generated by program "uuid" is in big endian and it is +also stored in big endian in disk GPT. +Partitions layout can be printed by typing "mmc part". Note that each partition +GUID has different byte order than UUID generated before, this is because first +three blocks of GUID string are in Little Endian. -- cgit v1.1 From 04d2f0a9f33112bd70ce4d9c451fdca1682e3a59 Mon Sep 17 00:00:00 2001 From: Tom Rini Date: Fri, 4 Apr 2014 10:09:19 -0400 Subject: 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 --- doc/README.generic-board | 189 ----------------------------------------------- 1 file changed, 189 deletions(-) delete mode 100644 doc/README.generic-board (limited to 'doc') diff --git a/doc/README.generic-board b/doc/README.generic-board deleted file mode 100644 index 50d3a26..0000000 --- a/doc/README.generic-board +++ /dev/null @@ -1,189 +0,0 @@ -# -# (C) Copyright 2014 Google, Inc -# Simon Glass -# -# SPDX-License-Identifier: GPL-2.0+ -# - -DEPRECATION NOTICE FOR 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//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//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 -- cgit v1.1