Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Daniel,
On Fri, 28 Mar 2014 21:35:37 +0100
Daniel Schwierzeck daniel.schwierz...@gmail.com wrote:
2014-03-28 3:25 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com:
Those boards have linker errors, but I do not understand yet why. For
example on ARM the linker complains about multiple definition of
board_init() and board_eth_init(). The solely difference is that there
are one or two additional intermediate objects (board/built-in.o and
if necessary board/VENDOR/built-in.o). But board/built-in.o and
board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o
contain the same symbols and object code. The strange thing is that
the error only affects some boards.
Have you figured out the multiple definition error?
They are nasty ones and have their own linker scripts. :-(
For cm_t335 board, board/compulab/cm_t335/u-boot.lds needs modifying.
--- a/board/compulab/cm_t335/u-boot.lds
+++ b/board/compulab/cm_t335/u-boot.lds
@@ -19,7 +19,7 @@ SECTIONS
{
*(.__image_copy_start)
CPUDIR/start.o (.text*)
- board/compulab/cm_t335/built-in.o (.text*)
+ board/built-in.o (.text*)
*(.text*)
}
that would fix it. But I looked through several linker scripts and saw
that some boards use that for size optimization. I think we should
ignore board/built-in.o and keep the direct linking of
board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o and
optionally board/vendor/common/built-in.o
I am not sure if that change has an impact to the size of outputs.
Anyway, in your plan, how would they be fixed?
BTW,
while read -r status arch cpu soc vendor board target options maintainers; do
case $status in
Active|Orphan)
;;
*)
continue
;;
esac
if [ $board = - ]; then
board=$target
fi
BOARD=${board^^}
BOARD=${BOARD/-/_}
This does not work correctly.
The only first occurrence of '-' will be replaced with '_'.
For exampile, FOO-BAR-BAZ will be converted to FOO_BAR-BAZ.
Some makefiles should be fixed.
--- a/board/Makefile
+++ b/board/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_BOARD_BF506F_EZKIT) += bf506f-ezkit/
obj-$(CONFIG_BOARD_BF518F_EZBRD) += bf518f-ezbrd/
obj-$(CONFIG_BOARD_BF525_UCR2) += bf525-ucr2/
obj-$(CONFIG_BOARD_BF526_EZBRD) += bf526-ezbrd/
-obj-$(CONFIG_BOARD_BF527_AD7160-EVAL) += bf527-ad7160-eval/
+obj-$(CONFIG_BOARD_BF527_AD7160_EVAL) += bf527-ad7160-eval/
obj-$(CONFIG_BOARD_BF527_EZKIT) += bf527-ezkit/
obj-$(CONFIG_BOARD_BF527_SDP) += bf527-sdp/
obj-$(CONFIG_BOARD_BF533_EZKIT) += bf533-ezkit/
diff --git a/board/earthlcd/Makefile b/board/earthlcd/Makefile
index 61956b4..f618674 100644
--- a/board/earthlcd/Makefile
+++ b/board/earthlcd/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_BOARD_FAVR_32-EZKIT) += favr-32-ezkit/
+obj-$(CONFIG_BOARD_FAVR_32_EZKIT) += favr-32-ezkit/
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-28 3:25 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com:
Those boards have linker errors, but I do not understand yet why. For
example on ARM the linker complains about multiple definition of
board_init() and board_eth_init(). The solely difference is that there
are one or two additional intermediate objects (board/built-in.o and
if necessary board/VENDOR/built-in.o). But board/built-in.o and
board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o
contain the same symbols and object code. The strange thing is that
the error only affects some boards.
Have you figured out the multiple definition error?
They are nasty ones and have their own linker scripts. :-(
For cm_t335 board, board/compulab/cm_t335/u-boot.lds needs modifying.
--- a/board/compulab/cm_t335/u-boot.lds
+++ b/board/compulab/cm_t335/u-boot.lds
@@ -19,7 +19,7 @@ SECTIONS
{
*(.__image_copy_start)
CPUDIR/start.o (.text*)
- board/compulab/cm_t335/built-in.o (.text*)
+ board/built-in.o (.text*)
*(.text*)
}
that would fix it. But I looked through several linker scripts and saw
that some boards use that for size optimization. I think we should
ignore board/built-in.o and keep the direct linking of
board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o and
optionally board/vendor/common/built-in.o
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Daniel,
Sorry not to have followed up earlier. I was sick in bed.
On Mon, 24 Mar 2014 21:35:15 +0100
Daniel Schwierzeck daniel.schwierz...@gmail.com wrote:
2014-03-24 7:35 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com:
Thanks for your effort. I think basicly we're going to the right direction.
But I am afraind more careful check is necessary before posting the
series.
I did build test on your patches on kconfig-support branch.
I noticed many boards would be broken:
- ARM
cm_t335 am335x_boneblack am335x_evm am335x_evm_nor am335x_evm_norboot
am335x_evm_spiboot am335x_evm_uart1 am335x_evm_uart2 am335x_evm_uart3
am335x_evm_uart4 am335x_evm_uart5 am335x_evm_usbspl h2200 palmld palmtc
palmtreo680 zipitz2 vpac270_ond_256 mx31ads lubbock
- AVR32
favr-32-ezkit
- Blackfin
bf527-ad7160-eval
- PowerPC
MVBLUE hermes svm_sc8xx ESTEEM192E ELPT860 FPS850L FPS860L NSCU SM850
TK885D TQM823L TQM823L_LCD TQM823M TQM850L TQM850M TQM855L TQM855M
TQM860L TQM860M TQM862L TQM862M TQM866M TQM885D TTTech virtlab2 wtk
MVSMR GENIETV )
Those boards have linker errors, but I do not understand yet why. For
example on ARM the linker complains about multiple definition of
board_init() and board_eth_init(). The solely difference is that there
are one or two additional intermediate objects (board/built-in.o and
if necessary board/VENDOR/built-in.o). But board/built-in.o and
board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o
contain the same symbols and object code. The strange thing is that
the error only affects some boards.
Have you figured out the multiple definition error?
They are nasty ones and have their own linker scripts. :-(
For cm_t335 board, board/compulab/cm_t335/u-boot.lds needs modifying.
--- a/board/compulab/cm_t335/u-boot.lds
+++ b/board/compulab/cm_t335/u-boot.lds
@@ -19,7 +19,7 @@ SECTIONS
{
*(.__image_copy_start)
CPUDIR/start.o (.text*)
- board/compulab/cm_t335/built-in.o (.text*)
+ board/built-in.o (.text*)
*(.text*)
}
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-24 7:35 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com: Thanks for your effort. I think basicly we're going to the right direction. But I am afraind more careful check is necessary before posting the series. I did build test on your patches on kconfig-support branch. I noticed many boards would be broken: - ARM cm_t335 am335x_boneblack am335x_evm am335x_evm_nor am335x_evm_norboot am335x_evm_spiboot am335x_evm_uart1 am335x_evm_uart2 am335x_evm_uart3 am335x_evm_uart4 am335x_evm_uart5 am335x_evm_usbspl h2200 palmld palmtc palmtreo680 zipitz2 vpac270_ond_256 mx31ads lubbock - AVR32 favr-32-ezkit - Blackfin bf527-ad7160-eval - PowerPC MVBLUE hermes svm_sc8xx ESTEEM192E ELPT860 FPS850L FPS860L NSCU SM850 TK885D TQM823L TQM823L_LCD TQM823M TQM850L TQM850M TQM855L TQM855M TQM860L TQM860M TQM862L TQM862M TQM866M TQM885D TTTech virtlab2 wtk MVSMR GENIETV ) Those boards have linker errors, but I do not understand yet why. For example on ARM the linker complains about multiple definition of board_init() and board_eth_init(). The solely difference is that there are one or two additional intermediate objects (board/built-in.o and if necessary board/VENDOR/built-in.o). But board/built-in.o and board/BOARD/built-in.o respectively board/VENDOR/BOARD/built-in.o contain the same symbols and object code. The strange thing is that the error only affects some boards. Could you run MAKEALL or buildman over all target boards and fix all errors? sure, if I find a solution And I want you to also fix a strange Makefile, board/synopsys/Makefile obj-$(CONFIG_BOARD_AXS101) += axs101/ obj-$(CONFIG_BOARD_NONE) += none/ fixed, I missed the special handling for the value of 'none' in the boad column -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-21 19:05 GMT+01:00 Tom Rini tr...@ti.com: On Thu, Mar 20, 2014 at 02:17:07PM +0100, Daniel Schwierzeck wrote: 2014-03-20 1:11 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com: [3] How to select board directoy by using boolean macros. If we try to emulate arch/arm/Makefile of Linux, board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a board-$(CONFIG_BOARD_AXS101) := axs101 board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 Like this? how about this: Makefile: ... lib-y += boards/ ... board/Makefile: obj-$(CONFIG_BOARD_A3000) += a3000/ ... obj-$(CONFIG_VENDOR_NVIDIA) += nvidia/ ... board/nvidia/Makefile: obj-y += common/ obj-$(CONFIG_BOARD_BEAVER) += beaver/ obj-$(CONFIG_BOARD_CARDHU) += cardhu/ ... Yes, would something like this be doable? Thanks! yes, I played with it and created a script to generate all necessary board and vendor Makefiles from boards.cfg. If we tweak mkconfig, It already works with the current mainline. The patches are pushed to: git://git.denx.de/u-boot-mips.git kconfig-support If you want I can post a patch series and also create patches for CPU and SOC directories. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Thu, Mar 20, 2014 at 08:48:04AM +0900, Masahiro Yamada wrote: Hi Tom, In message CACUy__Uc8-xDMRiJm7SM1UfF_hVAdHKN9_MZC5FV0D=zdra...@mail.gmail.com you wrote: maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. We have just created such a single point of information (boards.cfg), and now we're ripping it apart again :-( What Daniel said is right, we don't have a single point today, we have boards.cfg, wiki and other stuff. Being able to leverage get_maintainers.pl would be nice, even if it's a bit of a pain that we just got things into boards.cfg. On the other hand, it's good that we've just spent some time sorting and checking the information and it's a regex'able problem to go from boards.cfg to MAINTAINERS. We can move forward this work first apart from Kconfig, can't we? It is a cosmetic change so it can be merged even if MW is closed. BTW, is this task expected to me? Or can anyone do it? (This would be very appreciated.) I did some quick playing with sed and I can see a way to the end so I'll take care of that. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Thu, Mar 20, 2014 at 02:17:07PM +0100, Daniel Schwierzeck wrote: 2014-03-20 1:11 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com: Basicly I think it's a good idea, but I am afraid there are some problems. [1] First, in this case, how can we select the target board? Like this? choice prompt Board select default BOARD_SANDBOX config BOARD_VEXPRESS_AEMV8A bool vexpress_aemv8a board config BOARD_ARCANGEL4 bool arcangel4 board [ Snip: a thousand of boards ] endchoice If we run make config, a bunch of board choices would be displayed and be gone away quickly. For make menuconfig, it would be hard to select the board you are aiming at. Maybe we should choose it in the top-down order? Like this? I think only the top-down approach makes sense [2] CONFIG_CPU_ CONFIG_SOC_ CONFIG_VENDOR_ CONFIG_BOARD_ are systematic prefixes and easy to understand. But there are already some macros bound to specific CPUs, SoCs. For example, CONFIG_SOC_TEGRA30 would be the same as existing CONFIG_TEGRA30. We will have to merge macros with the same meaning. in the first step we could do something like this: config TEGRA30 bool config SOC_TEGRA30 bool select TEGRA30 [3] How to select board directoy by using boolean macros. If we try to emulate arch/arm/Makefile of Linux, board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a board-$(CONFIG_BOARD_AXS101) := axs101 board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 Like this? how about this: Makefile: ... lib-y += boards/ ... board/Makefile: obj-$(CONFIG_BOARD_A3000) += a3000/ ... obj-$(CONFIG_VENDOR_NVIDIA) += nvidia/ ... board/nvidia/Makefile: obj-y += common/ obj-$(CONFIG_BOARD_BEAVER) += beaver/ obj-$(CONFIG_BOARD_CARDHU) += cardhu/ ... Yes, would something like this be doable? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-20 1:11 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com: Basicly I think it's a good idea, but I am afraid there are some problems. [1] First, in this case, how can we select the target board? Like this? choice prompt Board select default BOARD_SANDBOX config BOARD_VEXPRESS_AEMV8A bool vexpress_aemv8a board config BOARD_ARCANGEL4 bool arcangel4 board [ Snip: a thousand of boards ] endchoice If we run make config, a bunch of board choices would be displayed and be gone away quickly. For make menuconfig, it would be hard to select the board you are aiming at. Maybe we should choose it in the top-down order? Like this? I think only the top-down approach makes sense [2] CONFIG_CPU_ CONFIG_SOC_ CONFIG_VENDOR_ CONFIG_BOARD_ are systematic prefixes and easy to understand. But there are already some macros bound to specific CPUs, SoCs. For example, CONFIG_SOC_TEGRA30 would be the same as existing CONFIG_TEGRA30. We will have to merge macros with the same meaning. in the first step we could do something like this: config TEGRA30 bool config SOC_TEGRA30 bool select TEGRA30 [3] How to select board directoy by using boolean macros. If we try to emulate arch/arm/Makefile of Linux, board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a board-$(CONFIG_BOARD_AXS101) := axs101 board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 Like this? how about this: Makefile: ... lib-y += boards/ ... board/Makefile: obj-$(CONFIG_BOARD_A3000) += a3000/ ... obj-$(CONFIG_VENDOR_NVIDIA) += nvidia/ ... board/nvidia/Makefile: obj-y += common/ obj-$(CONFIG_BOARD_BEAVER) += beaver/ obj-$(CONFIG_BOARD_CARDHU) += cardhu/ ... -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Dear Masahiro, In message 20140319135026.7a64.aa925...@jp.panasonic.com you wrote: +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. make randconfig or make allyesconfig will not work at all. I'm not sure if I understand your double negation here correctly. Avoiding the double negation, you state that ALL values in this defconfig are user-editable. I fully agree with Stephen that this should not be the case. I'm afraid we are approaching one of the areas where we run into problems if we try to reuse Kconfig as done in Linux, without changes. As Stephen already explained, we have the situation that there are certain settings that are not actually supported to be user-editable. There is a plan to move user-editable macros to Kconfig. For example, CONFIG_BAUDRATE. Yes, this is a good example for a setting where the user might want to adjust a setting, and where it is harmless to do so. Or someone might to disable CONFIG_CMD_* to reduce the binary size. Agreed, too - a user may want to enable (or disable) a specific set of commands in his configuration - but this is already one of the more complicated cases, as there will be a ton of dependencies you will have to include. On the other hand, a user should probably not be able to change the maintainer name, and similar so for a large number of other values. Following the originally intended logic of the naming scheme, only the CONFIG_ variables should show up here, where CONFIG_SYS_ variables should be not changable like this - or at least require some specific expert menu mode. We definitely need defconfig. This is OK - the question is, what should it contain. In my opinion, we should fiond here the user changable settings (i. e. CONFIG_ stuff), but not the unchangable things (like CONFIG_SYS_). Yes, I am aware that there is a lot of incorrectly chosen names, i. e. cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this adds to the complexity of converting to Kconfig. I believe the right way to reuse the Linux's Kconfig with minimum modification. Whithout modification, we will probably have to restrict ourself to the really simple, user-configurable options - i. e. the CONFIG_ set of options (and even then we will either have to make a number of exceptions, and/or rename a number of such names, and/or provide in some cases quite complex dependencies). 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 Anyone can count the seeds in an apple. No one can count the apples in a seed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Wolfgang, On Wed, 19 Mar 2014 10:56:46 +0100 Wolfgang Denk w...@denx.de wrote: Dear Masahiro, In message 20140319135026.7a64.aa925...@jp.panasonic.com you wrote: +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. make randconfig or make allyesconfig will not work at all. I'm not sure if I understand your double negation here correctly. Avoiding the double negation, you state that ALL values in this defconfig are user-editable. Oops, sorry. What I wanted to say is: None of settings in Kconfig in this series is user-editable. I fully agree with Stephen that this should not be the case. I'm afraid we are approaching one of the areas where we run into problems if we try to reuse Kconfig as done in Linux, without changes. As Stephen already explained, we have the situation that there are certain settings that are not actually supported to be user-editable. If prompt is not specified, the entry will not appear on make config, make menuconfig, etc. Linux Kernel does this for user-uneditable CONFIG. The following is a snippet from arch/arm/Kconfig of Linux Kernel. config STACKTRACE_SUPPORT bool default y config HAVE_LATENCYTOP_SUPPORT bool depends on !SMP default y config LOCKDEP_SUPPORT bool default y config TRACE_IRQFLAGS_SUPPORT bool default y config RWSEM_GENERIC_SPINLOCK bool default y Above are forced to the default value. We should do this in U-Boot too. This is OK - the question is, what should it contain. In my opinion, we should fiond here the user changable settings (i. e. CONFIG_ stuff), but not the unchangable things (like CONFIG_SYS_). Yes, I am aware that there is a lot of incorrectly chosen names, i. e. cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this adds to the complexity of converting to Kconfig. For example, CONFIG_SYS_PROMPT. I believe the right way to reuse the Linux's Kconfig with minimum modification. Whithout modification, we will probably have to restrict ourself to the really simple, user-configurable options - i. e. the CONFIG_ set of options (and even then we will either have to make a number of exceptions, and/or rename a number of such names, and/or provide in some cases quite complex dependencies). This is the outcome we have developed. What we should do it to fix them correctly, not to change Kconfig concept. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-19 11:51 GMT+01:00 Masahiro Yamada yamad...@jp.panasonic.com: Hi Wolfgang, On Wed, 19 Mar 2014 10:56:46 +0100 Wolfgang Denk w...@denx.de wrote: Dear Masahiro, In message 20140319135026.7a64.aa925...@jp.panasonic.com you wrote: +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. make randconfig or make allyesconfig will not work at all. I'm not sure if I understand your double negation here correctly. Avoiding the double negation, you state that ALL values in this defconfig are user-editable. Oops, sorry. What I wanted to say is: None of settings in Kconfig in this series is user-editable. I fully agree with Stephen that this should not be the case. I'm afraid we are approaching one of the areas where we run into problems if we try to reuse Kconfig as done in Linux, without changes. As Stephen already explained, we have the situation that there are certain settings that are not actually supported to be user-editable. If prompt is not specified, the entry will not appear on make config, make menuconfig, etc. Linux Kernel does this for user-uneditable CONFIG. The following is a snippet from arch/arm/Kconfig of Linux Kernel. config STACKTRACE_SUPPORT bool default y config HAVE_LATENCYTOP_SUPPORT bool depends on !SMP default y config LOCKDEP_SUPPORT bool default y config TRACE_IRQFLAGS_SUPPORT bool default y config RWSEM_GENERIC_SPINLOCK bool default y Above are forced to the default value. We should do this in U-Boot too. agree. But at first we should introduce Kconfig files in all arch, CPU, SOC, SOC common, board vendor, board and driver directories where we put all CONFIG_SYS_ symbols. We also need to convert the current config options for CPU, SOC, vendor and board. For example: CONFIG_SYS_CPU=armv7 CONFIG_SOC_DIR=y CONFIG_SYS_SOC=tegra30 CONFIG_SYS_BOARD=beaver CONFIG_VENDOR_DIR=y CONFIG_SYS_VENDOR=nvidia CONFIG_SYS_CONFIG_NAME=beaver should be converted to something like this: CONFIG_CPU_ARMV7=y CONFIG_SOC_TEGRA30=y CONFIG_VENDOR_NVIDIA=y CONFIG_BOARD_BEAVER=y Then we can use the Kconfig symbol dependencies to create a minimal working board config. For example: board/nvidia/beaver/Kconfig: config BOARD_BEAVER bool board description select VENDOR_NVIDIA select SOC_TEGRA30 select SPL ... arch/arm/cpu/armv7/tegra30/Kconfig: config SOC_TEGRA30 bool select ARMV7 ... The beaver_defconfig file could reduced then to CONFIG_BOARD_BEAVER=y and some default user-editable options. ideally the current target make beaver_config could be implemented as echo CONFIG_BOARD_BEAVER=y .config make oldconfig This is OK - the question is, what should it contain. In my opinion, we should fiond here the user changable settings (i. e. CONFIG_ stuff), but not the unchangable things (like CONFIG_SYS_). Yes, I am aware that there is a lot of incorrectly chosen names, i. e. cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this adds to the complexity of converting to Kconfig. For example, CONFIG_SYS_PROMPT. I believe the right way to reuse the Linux's Kconfig with minimum modification. Whithout modification, we will probably have to restrict ourself to the really simple, user-configurable options - i. e. the CONFIG_ set of options (and
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Mon, Mar 17, 2014 at 05:52:59PM +0900, Masahiro Yamada wrote:
In Kconfig, we use *_defconfig files for board configuration.
In Linux Kernel, they are located under arch/${ARCH}/configs/ directory.
It works in Linux Kernel because ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH before the board configuration.
That is why *_defconfig files over all architectures should be
moved into one directory ./configs/.
(The problem is configs/ directory contains more than 1200 files!)
Besides, we must configure boards for SPL and TPL too
if they are supported.
For those boards, defconfig files with the same name are placed
in spl/configs/, tpl/configs/ directories.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
So, what this series is doing, roughly, is turning just the boards.cfg
entry into a small Kconfig snippet, and saying we'll keep using
include/configs/foo.h for most of the work. This is just the first step
in moving away from include/configs/foo.h eventually, yes?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Dear Daniel Schwierzeck, please do not full-quote. Thanks. In message CACUy__Uc8-xDMRiJm7SM1UfF_hVAdHKN9_MZC5FV0D=zdra...@mail.gmail.com you wrote: maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. We have just created such a single point of information (boards.cfg), and now we're ripping it apart again :-( 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 It is better to have tried and failed than to have failed to try, but the result's the same. - Mike Dennison ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Wed, Mar 19, 2014 at 03:20:49PM +0100, Wolfgang Denk wrote: Dear Daniel Schwierzeck, please do not full-quote. Thanks. In message CACUy__Uc8-xDMRiJm7SM1UfF_hVAdHKN9_MZC5FV0D=zdra...@mail.gmail.com you wrote: maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. We have just created such a single point of information (boards.cfg), and now we're ripping it apart again :-( What Daniel said is right, we don't have a single point today, we have boards.cfg, wiki and other stuff. Being able to leverage get_maintainers.pl would be nice, even if it's a bit of a pain that we just got things into boards.cfg. On the other hand, it's good that we've just spent some time sorting and checking the information and it's a regex'able problem to go from boards.cfg to MAINTAINERS. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On 03/18/2014 10:50 PM, Masahiro Yamada wrote: diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com ... Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. Absolutely not at all. Any board contains a specific SoC. Each specific SoC is a particular CPU architecture and type, etc. In that case, all boards must have board/*/Kconfig to automatically select correct CONFIG_SYS_VENDOR, CONFIG_SYS_SOC, etc. Yes. I would fully expect that. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Tom, So, what this series is doing, roughly, is turning just the boards.cfg entry into a small Kconfig snippet, and saying we'll keep using include/configs/foo.h for most of the work. This is just the first step in moving away from include/configs/foo.h eventually, yes? Yes, exactly. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Tom, In message CACUy__Uc8-xDMRiJm7SM1UfF_hVAdHKN9_MZC5FV0D=zdra...@mail.gmail.com you wrote: maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. We have just created such a single point of information (boards.cfg), and now we're ripping it apart again :-( What Daniel said is right, we don't have a single point today, we have boards.cfg, wiki and other stuff. Being able to leverage get_maintainers.pl would be nice, even if it's a bit of a pain that we just got things into boards.cfg. On the other hand, it's good that we've just spent some time sorting and checking the information and it's a regex'able problem to go from boards.cfg to MAINTAINERS. We can move forward this work first apart from Kconfig, can't we? It is a cosmetic change so it can be merged even if MW is closed. BTW, is this task expected to me? Or can anyone do it? (This would be very appreciated.) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Daniel, agree. But at first we should introduce Kconfig files in all arch, CPU, SOC, SOC common, board vendor, board and driver directories where we put all CONFIG_SYS_ symbols. We also need to convert the current config options for CPU, SOC, vendor and board. For example: CONFIG_SYS_CPU=armv7 CONFIG_SOC_DIR=y CONFIG_SYS_SOC=tegra30 CONFIG_SYS_BOARD=beaver CONFIG_VENDOR_DIR=y CONFIG_SYS_VENDOR=nvidia CONFIG_SYS_CONFIG_NAME=beaver should be converted to something like this: CONFIG_CPU_ARMV7=y CONFIG_SOC_TEGRA30=y CONFIG_VENDOR_NVIDIA=y CONFIG_BOARD_BEAVER=y Then we can use the Kconfig symbol dependencies to create a minimal working board config. For example: board/nvidia/beaver/Kconfig: config BOARD_BEAVER bool board description select VENDOR_NVIDIA select SOC_TEGRA30 select SPL ... arch/arm/cpu/armv7/tegra30/Kconfig: config SOC_TEGRA30 bool select ARMV7 ... The beaver_defconfig file could reduced then to CONFIG_BOARD_BEAVER=y and some default user-editable options. Basicly I think it's a good idea, but I am afraid there are some problems. [1] First, in this case, how can we select the target board? Like this? choice prompt Board select default BOARD_SANDBOX config BOARD_VEXPRESS_AEMV8A bool vexpress_aemv8a board config BOARD_ARCANGEL4 bool arcangel4 board [ Snip: a thousand of boards ] endchoice If we run make config, a bunch of board choices would be displayed and be gone away quickly. For make menuconfig, it would be hard to select the board you are aiming at. Maybe we should choose it in the top-down order? Like this? (1) 1st Level : Architecture select choice prompt Architecture select config ARM bool ARM architecture . (2) 2rd Level: CPU select choice prompt CPU select depends on ARM config CPU_ARMV7 bool ARM v7 (3) 3rd level: SoC select choice prompt SoC select depends on CPU_ARMV7 config SOC_TEGRA bool Tegra SoC . (4) 4th level: Board select choice prompt Board select depends on SOC_TEGRA config BOARD_BEAVER bool Tegra SoC [2] CONFIG_CPU_ CONFIG_SOC_ CONFIG_VENDOR_ CONFIG_BOARD_ are systematic prefixes and easy to understand. But there are already some macros bound to specific CPUs, SoCs. For example, CONFIG_SOC_TEGRA30 would be the same as existing CONFIG_TEGRA30. We will have to merge macros with the same meaning. [3] How to select board directoy by using boolean macros. If we try to emulate arch/arm/Makefile of Linux, board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a board-$(CONFIG_BOARD_AXS101) := axs101 board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 Like this? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. You can send a follow-up patch to add arch/arm/cpu/armv7/tegra/Kconfig and desecribe them by yourself if you believe it is necessary. (although I doubt it.) Please do not get me wrong. This series provides the basic infrastructure. Expecting SoC-specific issues to this series is not fair. Tegra is not everything. BTW, tegra30 cannot automatically select SYS_VENDOR. It might be nvidia, or avionic-design. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On 03/18/2014 09:16 PM, Masahiro Yamada wrote: Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? I don't think there's any need at all for a defconfig file here. Perhaps the solution is to simply name these files something other than defconfig, but rather something else that reflects what the content really is. Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. Absolutely not at all. Any board contains a specific SoC. Each specific SoC is a particular CPU architecture and type, etc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. make randconfig or make allyesconfig will not work at all. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? I don't think there's any need at all for a defconfig file here. Perhaps the solution is to simply name these files something other than defconfig, but rather something else that reflects what the content really is. There is a plan to move user-editable macros to Kconfig. For example, CONFIG_BAUDRATE. Or someone might to disable CONFIG_CMD_* to reduce the binary size. We definitely need defconfig. Renaming it to something else will break the Kconfig infrastructure. I believe the right way to reuse the Linux's Kconfig with minimum modification. Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. Absolutely not at all. Any board contains a specific SoC. Each specific SoC is a particular CPU architecture and type, etc. In that case, all boards must have board/*/Kconfig to automatically select correct CONFIG_SYS_VENDOR, CONFIG_SYS_SOC, etc. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On 03/17/2014 02:52 AM, Masahiro Yamada wrote:
In Kconfig, we use *_defconfig files for board configuration.
In Linux Kernel, they are located under arch/${ARCH}/configs/ directory.
It works in Linux Kernel because ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH before the board configuration.
That is why *_defconfig files over all architectures should be
moved into one directory ./configs/.
(The problem is configs/ directory contains more than 1200 files!)
Besides, we must configure boards for SPL and TPL too
if they are supported.
For those boards, defconfig files with the same name are placed
in spl/configs/, tpl/configs/ directories.
diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig
new file mode 100644
index 000..fbf00f3
--- /dev/null
+++ b/configs/beaver_defconfig
@@ -0,0 +1,10 @@
+CONFIG_SPL=y
+CONFIG_ARM=y
+CONFIG_SYS_CPU=armv7
+CONFIG_SOC_DIR=y
+CONFIG_SYS_SOC=tegra30
+CONFIG_SYS_BOARD=beaver
+CONFIG_VENDOR_DIR=y
+CONFIG_SYS_VENDOR=nvidia
+CONFIG_SYS_CONFIG_NAME=beaver
+CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren
swar...@nvidia.com
This is odd; defconfig in the Linux kernel is for defining values for
user-editable configuration options. However, at least
CONFIG_BOARD_MAINTAINERS is a property of the board port, not something
the a user should be editing. Other values in this file feel very odd
too. For example, I would expect selecting SYS_SOC=tegra30 it
automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
