[03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN

Message ID 1443029143-22313-4-git-send-email-ryan.harkin@linaro.org
State New
Headers show

Commit Message

Ryan Harkin Sept. 23, 2015, 5:25 p.m.
As config migrates from board config files to Kconfig, when adding
CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
Kconfig support for CONFIG_SYS_BOOTM_LEN.

Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
CC: Simon Glass <sjg@chromium.org>
CC: Linus Walleij <linus.walleij@linaro.org>
---
 Kconfig | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Tom Rini Sept. 28, 2015, 3:10 p.m. | #1
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:

> As config migrates from board config files to Kconfig, when adding
> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
> Kconfig support for CONFIG_SYS_BOOTM_LEN.
> 
> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
> CC: Simon Glass <sjg@chromium.org>
> CC: Linus Walleij <linus.walleij@linaro.org>

Thanks for trying to do this.  The problem however is that you need to
use tools/moveconfig.py so that all of the other boards (which is a lot)
get updated too, otherwise they fail to build.

Since that's kind of a big thing, can you split this series into a v2 of
things which really should be in before the release, and then nice
cleanups like this which can go in once the merge window is open again?
Thanks!
Ryan Harkin Sept. 28, 2015, 3:35 p.m. | #2
Thanks Tom.

On 28 September 2015 at 16:10, Tom Rini <trini@konsulko.com> wrote:

> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
>
> > As config migrates from board config files to Kconfig, when adding
> > CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
> > Kconfig support for CONFIG_SYS_BOOTM_LEN.
> >
> > Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
> > CC: Simon Glass <sjg@chromium.org>
> > CC: Linus Walleij <linus.walleij@linaro.org>
>
> Thanks for trying to do this.  The problem however is that you need to
> use tools/moveconfig.py so that all of the other boards (which is a lot)
> get updated too, otherwise they fail to build.
>

Yes, I just read another email on the list about using moveconfig.py.
That's a big job, as you say.


> Since that's kind of a big thing, can you split this series into a v2 of
> things which really should be in before the release, and then nice
> cleanups like this which can go in once the merge window is open again?

Thanks!
>

So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other
boards for now?  Then submit a new series to use moveconfig.py to Kconfig?

I already tried using moveconfig.py for this and it fails on every
instance, from what I can tell.  I think the other board configs using the
shift operation makes this tricky.

I guess there are two options: make Kconfig support complex values (eg. to
allow << operators, etc.) or convert all the other boards to use absolute
values.  Of course, another option is to leave it alone.



>
> --
> Tom
>
Tom Rini Sept. 28, 2015, 4:03 p.m. | #3
On Mon, Sep 28, 2015 at 04:35:09PM +0100, Ryan Harkin wrote:
> Thanks Tom.
> 
> On 28 September 2015 at 16:10, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
> >
> > > As config migrates from board config files to Kconfig, when adding
> > > CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
> > > Kconfig support for CONFIG_SYS_BOOTM_LEN.
> > >
> > > Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > > CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
> > > CC: Simon Glass <sjg@chromium.org>
> > > CC: Linus Walleij <linus.walleij@linaro.org>
> >
> > Thanks for trying to do this.  The problem however is that you need to
> > use tools/moveconfig.py so that all of the other boards (which is a lot)
> > get updated too, otherwise they fail to build.
> >
> 
> Yes, I just read another email on the list about using moveconfig.py.
> That's a big job, as you say.
> 
> 
> > Since that's kind of a big thing, can you split this series into a v2 of
> > things which really should be in before the release, and then nice
> > cleanups like this which can go in once the merge window is open again?
> 
> Thanks!
> >
> 
> So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other
> boards for now?  Then submit a new series to use moveconfig.py to Kconfig?

Yeah, for this release at least.

> I already tried using moveconfig.py for this and it fails on every
> instance, from what I can tell.  I think the other board configs using the
> shift operation makes this tricky.
> 
> I guess there are two options: make Kconfig support complex values (eg. to
> allow << operators, etc.) or convert all the other boards to use absolute
> values.  Of course, another option is to leave it alone.

Well, if you can convince the Kconfig folks to take shift operations as
valid values on numeric inputs I bet other projects would appreciate it.
But it might be easier to start with a "simple" script that finds all of
the configs that define it to a shifted value and use printf to convert
it to hex.  Then moveconfig.py should be able to convert.
Hans de Goede Sept. 28, 2015, 7:22 p.m. | #4
Hi,

On 28-09-15 17:10, Tom Rini wrote:
> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
>
>> As config migrates from board config files to Kconfig, when adding
>> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
>> Kconfig support for CONFIG_SYS_BOOTM_LEN.
>>
>> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
>> CC: Simon Glass <sjg@chromium.org>
>> CC: Linus Walleij <linus.walleij@linaro.org>
>
> Thanks for trying to do this.  The problem however is that you need to
> use tools/moveconfig.py so that all of the other boards (which is a lot)
> get updated too, otherwise they fail to build.

No, just no, not more polluting of defconfig files with things which really
belong in a per SoC file not a per board file.

I think we can fix the "make savedefconfig" warnings by doing something like
this in a per SoC Kconfig file:

if ARCH_SUNXI

defconfig SYS_BOOTM_LEN
	default 0x0f000000 if ARCH_SUNXI

endif

The second "if ARCH_SUNXI" is necessary to stop the script calling
"make savedefconfig" for all boards to clean the defconfig files from complaining.

Please let set per SoC defaults this way rather then turning the defconfig
files in a mixture of board / soc settings where as they should really
only select the SoC and then contain board specific settings on top of
that.

Regards,

Hans
Tom Rini Sept. 28, 2015, 9:12 p.m. | #5
On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 28-09-15 17:10, Tom Rini wrote:
> >On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
> >
> >>As config migrates from board config files to Kconfig, when adding
> >>CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
> >>Kconfig support for CONFIG_SYS_BOOTM_LEN.
> >>
> >>Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> >>Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >>CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
> >>CC: Simon Glass <sjg@chromium.org>
> >>CC: Linus Walleij <linus.walleij@linaro.org>
> >
> >Thanks for trying to do this.  The problem however is that you need to
> >use tools/moveconfig.py so that all of the other boards (which is a lot)
> >get updated too, otherwise they fail to build.
> 
> No, just no, not more polluting of defconfig files with things which really
> belong in a per SoC file not a per board file.

Well, we should be putting SoC/arch-specific stuff into the defaults and
also using this as a chance to look at places where defaults differ
pointlessly.

But, I also hear your concern.  I see Masahiro has been working with
merge_config.sh from the kernel in the kernel.   How crazy would it be
to re-work things (in some cases..) to have a merge in the config
process so that there could be a sunxi-common config fragment.  Or
can/should we really just use default foo if Y in more places.
Hans de Goede Sept. 29, 2015, 8:38 a.m. | #6
Hi,

On 28-09-15 23:12, Tom Rini wrote:
> On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 28-09-15 17:10, Tom Rini wrote:
>>> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
>>>
>>>> As config migrates from board config files to Kconfig, when adding
>>>> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
>>>> Kconfig support for CONFIG_SYS_BOOTM_LEN.
>>>>
>>>> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> CC: Masahiro Yamada <yamada.m@jp.panasonic.com>
>>>> CC: Simon Glass <sjg@chromium.org>
>>>> CC: Linus Walleij <linus.walleij@linaro.org>
>>>
>>> Thanks for trying to do this.  The problem however is that you need to
>>> use tools/moveconfig.py so that all of the other boards (which is a lot)
>>> get updated too, otherwise they fail to build.
>>
>> No, just no, not more polluting of defconfig files with things which really
>> belong in a per SoC file not a per board file.
>
> Well, we should be putting SoC/arch-specific stuff into the defaults

Agreed, but where, do we add a long list of:

	default FOO if ARCH_BAR

To the Kconfig file where the actual CONFIG_SOMETHING gets defined, or
do we add it to board/bar/Kconfig ? Currently we've a bit of a mix,
I personally prefer the board/bar/Kconfig version as that puts everything for
one SoC(-family) in one place and it helps avoiding merge conflicts.

> and
> also using this as a chance to look at places where defaults differ
> pointlessly.
>
> But, I also hear your concern.  I see Masahiro has been working with
> merge_config.sh from the kernel in the kernel.   How crazy would it be
> to re-work things (in some cases..) to have a merge in the config
> process so that there could be a sunxi-common config fragment.

Either we then ask the user to take an extra step during building
(not a good idea IMHO), or we somehow need to automate this, which is
hard because figuring out which foo_common_config fragment belongs
to which board_defconfig file is going to be hard and / or will
involve a long list of hardcoded values in a Makefile or some such.

> Or
> can/should we really just use default foo if Y in more places.

I believe that this is the better option, currently board/sunxi/Kconfig
already has:

config SYS_CLK_FREQ
         default 912000000 if MACH_SUN7I
         default 1008000000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I

config SYS_CONFIG_NAME
         default "sun4i" if MACH_SUN4I
         default "sun5i" if MACH_SUN5I
         default "sun6i" if MACH_SUN6I
         default "sun7i" if MACH_SUN7I
         default "sun8i" if MACH_SUN8I
         default "sun9i" if MACH_SUN9I

Apparently these are not a problem for the script which is used to rewrite all
the defconfig-s, where as in the past having:

config CMD_FOO
	default y

in board/sunxi/Kconfig was a problem (it caused the script to emit
a ton of warnings IIRC) so I guess that doing something like:

config FOO
	default bar if ARCH_SUNXI

Will workaround the script issuing all kind of warnings, and then we
can keep per SoC(-family) defaults in board/foo/Kconfig.

Regards,

Hans

Patch hide | download patch | download mbox

diff --git a/Kconfig b/Kconfig
index 05a34f7..7783a13 100644
--- a/Kconfig
+++ b/Kconfig
@@ -190,6 +190,13 @@  config SYS_CLK_FREQ
 	help
 	  TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture
 
+config CONFIG_SYS_BOOTM_LEN
+	hex "Max uImage length"
+	help
+	  Normally compressed uImages are limited to an uncompressed size of
+	  8 MBytes. If this is not enough, you can define CONFIG_SYS_BOOTM_LEN
+	  to adjust this setting to your needs.
+
 endmenu		# Boot images
 
 source "common/Kconfig"