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.