Re: [U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
Dear Graeme Russ, In message calbutck062nsvsv0oq4evybxhv1hj7zorgxkclmpk-jfx3y...@mail.gmail.com you wrote: Pull request was sent a while ago and assigned to Wolfgang http://patchwork.ozlabs.org/patch/139891 Maybe Wolgang missed it or it is low on his priorities I haven't seen it... For some reason, this message was marked as read. Sorry. Will care about it ASAP. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
Hi, On Mon, Jan 16, 2012 at 10:03 PM, Simon Glass s...@chromium.org wrote: Hi, On Fri, Jan 6, 2012 at 4:24 PM, Simon Glass s...@chromium.org wrote: This series creates a generic board.c implementation which contains the essential functions of the major arch/xxx/lib/board.c files. I haven't had huge numbers of comments on this series, but there are a few. I plan to tidy these up and resubmit, dropping the RFC tag, sometime this week. Any patches / fixes to make this run properly on x86 / PPC would be gratefully accepted. An update - Graeme asked me to wait until the x86 refactor is pulled - still waiting for that. Hopefully soon. Regards, Simon Regards, Simon 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, some due to errors in the board config, some due to things that need fixing. I will address these with the final series if required. Note: the first group of commits are required for this series to build, but
Re: [U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
Hi Simon, On Thu, Feb 16, 2012 at 1:05 PM, Simon Glass s...@chromium.org wrote: Hi, On Mon, Jan 16, 2012 at 10:03 PM, Simon Glass s...@chromium.org wrote: Hi, On Fri, Jan 6, 2012 at 4:24 PM, Simon Glass s...@chromium.org wrote: This series creates a generic board.c implementation which contains the essential functions of the major arch/xxx/lib/board.c files. I haven't had huge numbers of comments on this series, but there are a few. I plan to tidy these up and resubmit, dropping the RFC tag, sometime this week. Any patches / fixes to make this run properly on x86 / PPC would be gratefully accepted. An update - Graeme asked me to wait until the x86 refactor is pulled - still waiting for that. Hopefully soon. Pull request was sent a while ago and assigned to Wolfgang http://patchwork.ozlabs.org/patch/139891 Maybe Wolgang missed it or it is low on his priorities arch/x86/cpu/cpu.c | 109 +-- arch/x86/cpu/interrupts.c|2 +- arch/x86/cpu/start.S | 33 +-- arch/x86/cpu/start16.S | 57 +++- arch/x86/include/asm/global_data.h | 21 +- arch/x86/include/asm/init_helpers.h | 44 +++ arch/x86/include/asm/init_wrappers.h | 42 +++ arch/x86/include/asm/processor.h | 24 ++- arch/x86/include/asm/relocate.h | 33 +++ arch/x86/include/asm/string.h|2 +- arch/x86/include/asm/u-boot-x86.h|5 + arch/x86/lib/Makefile|4 + arch/x86/lib/bios.S | 134 ++ arch/x86/lib/board.c | 517 ++ arch/x86/lib/cmd_boot.c | 64 + arch/x86/lib/init_helpers.c | 217 ++ arch/x86/lib/init_wrappers.c | 137 + arch/x86/lib/realmode_switch.S | 61 +++-- arch/x86/lib/relocate.c | 91 ++ arch/x86/lib/string.c| 61 arch/x86/lib/zimage.c|7 + 21 files changed, 1152 insertions(+), 513 deletions(-) create mode 100644 arch/x86/include/asm/init_helpers.h create mode 100644 arch/x86/include/asm/init_wrappers.h create mode 100644 arch/x86/include/asm/relocate.h create mode 100644 arch/x86/lib/cmd_boot.c create mode 100644 arch/x86/lib/init_helpers.c create mode 100644 arch/x86/lib/init_wrappers.c create mode 100644 arch/x86/lib/relocate.c As you can see, no changes outside x86, so a merge of u-boot-x86/master for building your new series should be safe Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
Hi Graeme, On Wed, Feb 15, 2012 at 6:28 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Feb 16, 2012 at 1:05 PM, Simon Glass s...@chromium.org wrote: Hi, On Mon, Jan 16, 2012 at 10:03 PM, Simon Glass s...@chromium.org wrote: Hi, On Fri, Jan 6, 2012 at 4:24 PM, Simon Glass s...@chromium.org wrote: This series creates a generic board.c implementation which contains the essential functions of the major arch/xxx/lib/board.c files. I haven't had huge numbers of comments on this series, but there are a few. I plan to tidy these up and resubmit, dropping the RFC tag, sometime this week. Any patches / fixes to make this run properly on x86 / PPC would be gratefully accepted. An update - Graeme asked me to wait until the x86 refactor is pulled - still waiting for that. Hopefully soon. Pull request was sent a while ago and assigned to Wolfgang http://patchwork.ozlabs.org/patch/139891 Maybe Wolgang missed it or it is low on his priorities arch/x86/cpu/cpu.c | 109 +-- arch/x86/cpu/interrupts.c | 2 +- arch/x86/cpu/start.S | 33 +-- arch/x86/cpu/start16.S | 57 +++- arch/x86/include/asm/global_data.h | 21 +- arch/x86/include/asm/init_helpers.h | 44 +++ arch/x86/include/asm/init_wrappers.h | 42 +++ arch/x86/include/asm/processor.h | 24 ++- arch/x86/include/asm/relocate.h | 33 +++ arch/x86/include/asm/string.h | 2 +- arch/x86/include/asm/u-boot-x86.h | 5 + arch/x86/lib/Makefile | 4 + arch/x86/lib/bios.S | 134 ++ arch/x86/lib/board.c | 517 ++ arch/x86/lib/cmd_boot.c | 64 + arch/x86/lib/init_helpers.c | 217 ++ arch/x86/lib/init_wrappers.c | 137 + arch/x86/lib/realmode_switch.S | 61 +++-- arch/x86/lib/relocate.c | 91 ++ arch/x86/lib/string.c | 61 arch/x86/lib/zimage.c | 7 + 21 files changed, 1152 insertions(+), 513 deletions(-) create mode 100644 arch/x86/include/asm/init_helpers.h create mode 100644 arch/x86/include/asm/init_wrappers.h create mode 100644 arch/x86/include/asm/relocate.h create mode 100644 arch/x86/lib/cmd_boot.c create mode 100644 arch/x86/lib/init_helpers.c create mode 100644 arch/x86/lib/init_wrappers.c create mode 100644 arch/x86/lib/relocate.c As you can see, no changes outside x86, so a merge of u-boot-x86/master for building your new series should be safe OK that's great, have pulled it in and rebased. Not sure why I missed it. Wolfgang are you going to pull this soon? I will make my generic board patch sit on top of it. Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
Hi, On Fri, Jan 6, 2012 at 4:24 PM, Simon Glass s...@chromium.org wrote: This series creates a generic board.c implementation which contains the essential functions of the major arch/xxx/lib/board.c files. I haven't had huge numbers of comments on this series, but there are a few. I plan to tidy these up and resubmit, dropping the RFC tag, sometime this week. Any patches / fixes to make this run properly on x86 / PPC would be gratefully accepted. Regards, Simon 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, some due to errors in the board config, some due to things that need fixing. I will address these with the final series if required. 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. Comments welcome. Changes in v2: - Change generic board to an opt-in system on a per-board basic - Add CONFIG_SYS_GENERIC_BOARD to
[U-Boot] [RFC PATCH v2 0/28] Create generic board init for ARM, x86, PPC
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, some due to errors in the board config, some due to things that need fixing. I will address these with the final series if required. 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. Comments welcome. Changes in v2: - Change generic board to an opt-in system on a per-board basic - Add CONFIG_SYS_GENERIC_BOARD to allow board to select generic board - Add PowerPC support - Rebase to master Simon Glass (28): arm: Change board baud_rate to ulong x86: Change board baud_rate to ulong arm: Only display frame buffer info if there is LCD/video support x86: Remove compiler warning in sc520_timer.c x86: Remove dead code in eNET x86: Add initial memory barrier macros ppc: Add initial memory barrier macros
