[U-Boot] switching to single .config configuration issues
Hi everyone,
I'm working on the latest u-boot 2015.04 trying to rebase my repository to latest code. And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config): For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Do you planning for another solution for this issue?
Thanks, Hanna
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for SPL. For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s" and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Yehuda
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for SPL. For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s" and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
- Is there any possibility that some files should be compiled for SPL only? (I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are boolean.
Best Regards Masahiro Yamada
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for SPL. For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig
to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s"
and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
Is there any possibility that some files should be compiled for SPL only? (I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be added as "t" option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are boolean.
Best Regards Masahiro Yamada
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be
there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for
SPL.
For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-- Best Regards Masahiro Yamada
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig
to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s"
and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
Is there any possibility that some files should be compiled for SPL only? (I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be added as "t" option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
Best Regards Masahiro Yamada
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be
there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for
SPL.
For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-- Best Regards Masahiro Yamada
Regards, Simon
Hey Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Sunday, May 03, 2015 21:55 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig
to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s"
and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
Is there any possibility that some files should be compiled for SPL only? (I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be added as "t"
option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are
boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
We are looking for a very small SPL image that will fit into internal SRAM. Therefore we want to compile the minimal set of drivers into the SPL. We have added all our drivers to Kconfig infrastructure (not mainlined yet) and so each driver We add to u-boot (like PCIe) will be added to SPL and would require manual removal using the dedicated H file
Best Regards Masahiro Yamada
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be
there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for
SPL.
For example CONFIG_SPL_I2C_SUPPORT. This is much the same as
before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-- Best Regards Masahiro Yamada
Regards, Simon
Hi,
On 4 May 2015 at 05:34, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Sunday, May 03, 2015 21:55 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig
to "y" or "m".
With minor modifications to the Makefile, SPL target will compile "obj-s"
and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
Is there any possibility that some files should be compiled for SPL only? (I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be added as "t"
option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are
boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
We are looking for a very small SPL image that will fit into internal SRAM. Therefore we want to compile the minimal set of drivers into the SPL. We have added all our drivers to Kconfig infrastructure (not mainlined yet) and so each driver We add to u-boot (like PCIe) will be added to SPL and would require manual removal using the dedicated H file
I see. Let's see what Masahiro thinks about this. One good thing with this proposal is that we would still only have a single config source file (.config), but I cannot see how it could be implemented without having multiple output autoconf.h files.
How many options do you need to add for manual removal?
Regards, Simon
Best Regards Masahiro Yamada
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Wednesday, April 29, 2015 6:06 To: Hanna Hawa Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada Subject: Re: switching to single .config configuration issues
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote: > Hi everyone, > > > > I’m working on the latest u-boot 2015.04 trying to rebase my > repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be
there.
> > And I have question regarding patch e02ee2548afe (kconfig: > switch to single .config configuration) > > > > Issues that I face in the current solution (single .config): > > For my usage most of the CONFIG options will not supported in > the SPL, we need the SPL very tiny and most of the CONFIG will > be enabled in the u-boot, need to undef/disable(set=n) for every > CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h > > Also for future usage if we want to delete the defines of the > commands from the include file and move it to defconfig file, > then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for
SPL.
For example CONFIG_SPL_I2C_SUPPORT. This is much the same as
before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
> > > > Do you planning for another solution for this issue?
Also, if you push your tree to github (or somewhere) I or Masahiro might be able to comment on specifics.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-- Best Regards Masahiro Yamada
Regards, Simon
Hi Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Tuesday, May 05, 2015 6:28 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi,
On 4 May 2015 at 05:34, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Sunday, May 03, 2015 21:55 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com
wrote:
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak
Hey Simon, Masahiro
May I suggest an alternative solution to this issue.
What if each Kconfigs option could be set as "y" (compile for u-boot only )or "s" (compile for u-boot and SPL) Just as the kernel can set Kconfig
to "y" or "m".
With minor modifications to the Makefile, SPL target will compile
"obj-s"
and u-boot target will compile "obj-s" and "obj-y"
What do you think ?
Interesting.
A little comments.
- Is there any possibility that some files should be compiled for SPL
only?
(I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be
added as "t"
option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are
boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
We are looking for a very small SPL image that will fit into internal SRAM. Therefore we want to compile the minimal set of drivers into the SPL. We have added all our drivers to Kconfig infrastructure (not mainlined yet) and so each driver We add to u-boot (like PCIe) will be added to SPL and would require manual removal using the dedicated H file
I see. Let's see what Masahiro thinks about this. One good thing with this proposal is that we would still only have a single config source file (.config), but I cannot see how it could be implemented without having multiple output autoconf.h files.
Linux actually uses a single autoconf.h file by suffixing module configs with _MODULE. Then all the other build scripts somehow take advantage of that
How many options do you need to add for manual removal?
I don’t have the exact count but somewhere around 10-20. However I think the number itself is not the issue. The thing is that you have to update this list every time you modify your defconfig otherwise your SPL start bloating. That is a bit of a nuisance considering defconfig changes may be frequent during development and ramp-up time
Regards, Simon
Best Regards Masahiro Yamada
> -----Original Message----- > From: sjg@google.com [mailto:sjg@google.com] On Behalf Of
Simon
Glass
> Sent: Wednesday, April 29, 2015 6:06 > To: Hanna Hawa > Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada > Subject: Re: switching to single .config configuration issues > > +Masahiro (new address) > > Hi Hanna, > > On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com
wrote:
> > Hi everyone, > > > > > > > > I’m working on the latest u-boot 2015.04 trying to rebase my > > repository to latest code. > > I would suggest going with upstream/master (targeting 2015.07) > since there are several driver model changes since 2015.04 > (USB, PCI, Ethernet). There are still patches going in but the > bulk of it should be
there.
> > > > > And I have question regarding patch e02ee2548afe (kconfig: > > switch to single .config configuration) > > > > > > > > Issues that I face in the current solution (single .config): > > > > For my usage most of the CONFIG options will not supported in > > the SPL, we need the SPL very tiny and most of the CONFIG > > will be enabled in the u-boot, need to undef/disable(set=n) > > for every CONFIG in scripts/Makefile.uncmd_spl/ > > include/config_uncmd_spl.h > > > > Also for future usage if we want to delete the defines of the > > commands from the include file and move it to defconfig file, > > then need to undef them in the SPL code. > > Masahiro is the expert here. The idea is to use SPL-specific > options for
SPL.
> For example CONFIG_SPL_I2C_SUPPORT. This is much the same as
before.
> > I suggest you create some SPL options for your new features, so > that they are only enabled in SPL when you want them. > > > > > > > > > Do you planning for another solution for this issue? > > Also, if you push your tree to github (or somewhere) I or > Masahiro might be able to comment on specifics. > > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-- Best Regards Masahiro Yamada
Regards, Simon
Hi.
2015-05-05 20:16 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hi Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Tuesday, May 05, 2015 6:28 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi,
On 4 May 2015 at 05:34, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Sunday, May 03, 2015 21:55 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com
wrote:
Hey Masahiro
-----Original Message----- From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] Sent: Thursday, April 30, 2015 4:46 To: Yehuda Yitschak Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
2015-04-29 14:23 GMT+09:00 Yehuda Yitschak
> Hey Simon, Masahiro > > May I suggest an alternative solution to this issue. > > What if each Kconfigs option could be set as "y" (compile for > u-boot only )or "s" (compile for u-boot and SPL) Just as the > kernel can set Kconfig to "y" or "m". > > With minor modifications to the Makefile, SPL target will compile
"obj-s"
and u-boot target will compile "obj-s" and "obj-y" > > What do you think ?
Interesting.
A little comments.
- Is there any possibility that some files should be compiled for SPL
only?
(I do not think we have much.)
Perhaps, obj-y : for U-boot only obj-s : for SPL only oby-ys: for both I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be
added as "t"
option.
- This idea is only applicable for bool options. We still have to keep duplication for int/hex options such as
CONFIG_SPL_TEXT_BASE.
But, this idea will help clean up much because most of configs are
boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
We are looking for a very small SPL image that will fit into internal SRAM. Therefore we want to compile the minimal set of drivers into the SPL. We have added all our drivers to Kconfig infrastructure (not mainlined yet) and so each driver We add to u-boot (like PCIe) will be added to SPL and would require manual removal using the dedicated H file
Or we can use "ifndef CONFIG_SPL_BUILD" to keep drivers from being compiled into SPL. (and this is what we have done so far. For example, drivers/mtd/nand/Makefile)
ifndef CONFIG_SPL_BUILD obj-$(CONFIG_YOUR_OWN_DRIVER) += your_driver.o endif
I know this is an ugly solution...
BTW, barebox (U-boot v2) uses "pbl-y" for objects that should be compiled into a pre-bootloader (the same concept as what we call SPL).
obj-(CONFIG_FOO) += foo.o <--- compiled for barebox proper pbl-(CONFIG_PBL_FOO) += foo.o <--- compiled for pre-bootloader
Better to bollow this idea?
I see. Let's see what Masahiro thinks about this. One good thing with this proposal is that we would still only have a single config source file (.config), but I cannot see how it could be implemented without having multiple output autoconf.h files.
Linux actually uses a single autoconf.h file by suffixing module configs with _MODULE. Then all the other build scripts somehow take advantage of that
Right. This is the way we distinguish modules from built-in drivers in Linux.
Maybe we can add _SPL suffix, but please let me clarify this idea. How does "select FOO" work?
CONFIG_FOO should be enabled for U-Boot only (CONFIG_FOO=y), or also for SPL (CONFIG_FOO=a)? How about "depends on FOO"?
How many options do you need to add for manual removal?
I don’t have the exact count but somewhere around 10-20. However I think the number itself is not the issue. The thing is that you have to update this list every time you modify your defconfig otherwise your SPL start bloating. That is a bit of a nuisance considering defconfig changes may be frequent during development and ramp-up time
I agree.
+Tom
Hi Masahiro,
On 6 May 2015 at 22:04, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi.
2015-05-05 20:16 GMT+09:00 Yehuda Yitschak yehuday@marvell.com:
Hi Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Tuesday, May 05, 2015 6:28 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi,
On 4 May 2015 at 05:34, Yehuda Yitschak yehuday@marvell.com wrote:
Hey Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon
Glass
Sent: Sunday, May 03, 2015 21:55 To: Yehuda Yitschak Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de Subject: Re: [U-Boot] switching to single .config configuration issues
Hi Yehuda,
On 30 April 2015 at 01:21, Yehuda Yitschak yehuday@marvell.com
wrote:
Hey Masahiro
> -----Original Message----- > From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] > Sent: Thursday, April 30, 2015 4:46 > To: Yehuda Yitschak > Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de > Subject: Re: [U-Boot] switching to single .config configuration > issues > > Hi Yehuda, > > > 2015-04-29 14:23 GMT+09:00 Yehuda Yitschak
> > Hey Simon, Masahiro > > > > May I suggest an alternative solution to this issue. > > > > What if each Kconfigs option could be set as "y" (compile for > > u-boot only )or "s" (compile for u-boot and SPL) Just as the > > kernel can set Kconfig > to "y" or "m". > > > > With minor modifications to the Makefile, SPL target will compile
"obj-s"
> and u-boot target will compile "obj-s" and "obj-y" > > > > What do you think ? > > > Interesting. > > A little comments. > > - Is there any possibility that some files should be compiled for SPL
only?
> (I do not think we have much.) > > Perhaps, obj-y : for U-boot only > obj-s : for SPL only > oby-ys: for both > I am not sure..
How about "a" (as in all targets) instead of "sy". It will look better in the menuconfig square brackets Maybe TPL should also be
added as "t"
option.
> > - This idea is only applicable for bool options. > We still have to keep duplication for int/hex options such as > CONFIG_SPL_TEXT_BASE. > > But, this idea will help clean up much because most of configs > are
boolean.
I am still not sure what sorts of things are getting compiled int SPL, and thus causing problems. Can you please provide a few details?
We are looking for a very small SPL image that will fit into internal SRAM. Therefore we want to compile the minimal set of drivers into the SPL. We have added all our drivers to Kconfig infrastructure (not mainlined yet) and so each driver We add to u-boot (like PCIe) will be added to SPL and would require manual removal using the dedicated H file
Or we can use "ifndef CONFIG_SPL_BUILD" to keep drivers from being compiled into SPL. (and this is what we have done so far. For example, drivers/mtd/nand/Makefile)
ifndef CONFIG_SPL_BUILD obj-$(CONFIG_YOUR_OWN_DRIVER) += your_driver.o endif
I know this is an ugly solution...
It works fine so long as no board wants the driver in SPL.
BTW, barebox (U-boot v2) uses "pbl-y" for objects that should be compiled into a pre-bootloader (the same concept as what we call SPL).
obj-(CONFIG_FOO) += foo.o <--- compiled for barebox proper pbl-(CONFIG_PBL_FOO) += foo.o <--- compiled for pre-bootloader
Better to bollow this idea?
A bit annoying that we then have to repeat every file twice (or three times for TPL).
I see. Let's see what Masahiro thinks about this. One good thing with this proposal is that we would still only have a single config source file (.config), but I cannot see how it could be implemented without having multiple output autoconf.h files.
Linux actually uses a single autoconf.h file by suffixing module configs with _MODULE. Then all the other build scripts somehow take advantage of that
Right. This is the way we distinguish modules from built-in drivers in Linux.
Maybe we can add _SPL suffix, but please let me clarify this idea. How does "select FOO" work?
CONFIG_FOO should be enabled for U-Boot only (CONFIG_FOO=y), or also for SPL (CONFIG_FOO=a)? How about "depends on FOO"?
Do you then need to cover every combination of U-Boot, SPL, TPL?
How many options do you need to add for manual removal?
I don’t have the exact count but somewhere around 10-20. However I think the number itself is not the issue. The thing is that you have to update this list every time you modify your defconfig otherwise your SPL start bloating. That is a bit of a nuisance considering defconfig changes may be frequent during development and ramp-up time
I agree.
For this, your spl-y idea is probably easiest.
Regards, Simon
Hi Hanna, Simon,
2015-04-29 12:05 GMT+09:00 Simon Glass sjg@chromium.org:
+Masahiro (new address)
Hi Hanna,
On 27 April 2015 at 07:43, Hanna Hawa hannah@marvell.com wrote:
Hi everyone,
I’m working on the latest u-boot 2015.04 trying to rebase my repository to latest code.
I would suggest going with upstream/master (targeting 2015.07) since there are several driver model changes since 2015.04 (USB, PCI, Ethernet). There are still patches going in but the bulk of it should be there.
And I have question regarding patch e02ee2548afe (kconfig: switch to single .config configuration)
Issues that I face in the current solution (single .config):
For my usage most of the CONFIG options will not supported in the SPL, we need the SPL very tiny and most of the CONFIG will be enabled in the u-boot, need to undef/disable(set=n) for every CONFIG in scripts/Makefile.uncmd_spl/ include/config_uncmd_spl.h
Also for future usage if we want to delete the defines of the commands from the include file and move it to defconfig file, then need to undef them in the SPL code.
Masahiro is the expert here. The idea is to use SPL-specific options for SPL. For example CONFIG_SPL_I2C_SUPPORT. This is much the same as before.
I suggest you create some SPL options for your new features, so that they are only enabled in SPL when you want them.
As Simon said, our current solution is to add CONFIG_SPL_-prefixed ones to config options we want to turn on/off separately.
participants (4)
-
Hanna Hawa -
Masahiro Yamada -
Simon Glass -
Yehuda Yitschak