[U-Boot] switching to single .config configuration issues

[Masahiro Yamada]

Hi.

2015-05-05 20:16 GMT+09:00 Yehuda Yitschak <yehuday at marvell.com>:
> Hi Simon
>
>> -----Original Message-----
>> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
>> Sent: Tuesday, May 05, 2015 6:28
>> To: Yehuda Yitschak
>> Cc: Masahiro Yamada; Hanna Hawa; u-boot at lists.denx.de
>> Subject: Re: [U-Boot] switching to single .config configuration issues
>>
>> Hi,
>>
>> On 4 May 2015 at 05:34, Yehuda Yitschak <yehuday at marvell.com> wrote:
>> > Hey Simon
>> >
>> >> -----Original Message-----
>> >> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon
>> Glass
>> >> Sent: Sunday, May 03, 2015 21:55
>> >> To: Yehuda Yitschak
>> >> Cc: Masahiro Yamada; Hanna Hawa; u-boot at 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 at marvell.com>
>> wrote:
>> >> > Hey Masahiro
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
>> >> >> Sent: Thursday, April 30, 2015 4:46
>> >> >> To: Yehuda Yitschak
>> >> >> Cc: Simon Glass; Hanna Hawa; u-boot at 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 at 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


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.



-- 
Best Regards
Masahiro Yamada